One document matched: draft-ietf-ipsra-pic-00.txt
IP Secure Remote Access WG Y. Sheffer, RADGUARD
Internet Draft H. Krawczyk, Technion
Document: draft-ietf-ipsra-pic-00.txt
Expires: September 2000 March 2000
PIC, A Pre-IKE Credential Provisioning Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document presents a method to bootstrap IPSec authentication via
an "Authentication Server" (AS) using legacy user authentication
(e.g., RADIUS). The client machine communicates with the AS using a
key exchange protocol authenticated by the server only, and the
derived keys are used to protect the legacy user authentication. Once
the user is authenticated, the client machine obtains credentials
and/or keys from the AS that can be later used to authenticate the
client in a standard IKE exchange with an IPSec-enabled security
gateway. The later stage does not require user intervention. The
proposed server-authenticated key exchange uses an ISAKMP-based
protocol, similar to a simplified IKE exchange, and arbitrary legacy
authentication is supported via the use of XAUTH mechanisms.
2. Introduction
Despite the growing popularity of PKI, legacy user authentication is
not going away. There have been several proposals to integrate legacy
authentication directly into the IKE framework, such as [7] and [2].
Recently Bellovin and Moskowitz proposed to offload this task into a
separate server, called an Authentication Server (AS). Some of the
advantages of a separate authentication server are:
Sheffer, Krawczyk Internet Draft 1
PIC, A Pre-IKE Credential Provisioning Protocol March 2000
- The security gateway may implement IKE/IPSec only, without worrying
about legacy authentication. The same gateway can be deployed in
PKI-based and legacy-based organizations.
- A denial-of-service attack on the AS cannot compromise existing
connections at the gateway (thus alleviating the damage of such a
potential attack). This reduces the amount of work that needs to
be done to secure the AS against DoS attacks.
- The AS may or may not be collocated with a gateway, per the
organizationĘs policy. A separate AS off-loads the security
gateway but may involve extra cost.
This document adopts this separation of an Authentication Server.
However, in contrast to the mechanism proposed in [4] which uses
IPSec-unrelated protocols TLS and HTTP, the current solution is based
on simplified ISAKMP and IKE mechanisms. In particular it uses the
XAuth protocol [3] to support multiple forms of legacy user
authentication (e.g. RADIUS). Following the proposal in [4], at the
end of the interaction with AS the client machine obtains credentials
and/or keys that can be later used by the client to perform regular
IKE authentication with an IPSec-enabled gateway. The current draft
does not define the particular form of credentials exchange which can
take any of the four forms defined in [4].
This proposal overcomes some of the shortcomings in the solution of
[4]. In particular, it avoids the use of HTTP-based authentication
which is not general enough to support authentication schemes in
common use today, and avoids the need to support a full TLS
implementation (this is especially advantageous in the case where the
AS is collocated with an IPSec security gateway which does not
supports TLS).
It should be emphasized that this protocol requires no modification
to IKE. Instead it uses simplified elements of ISAKMP and IKE to
obtain a much less ambitious goal than general IKE, namely, it is
limited to the secure provisioning of credentials for successfully
authenticated users.
2.1 Protocol Entities
User: the human being at the client machine.
Client: a client machine talking to the authentication server and to
the security gateway.
Authentication server (AS): a server at the organization which can
relay the user's authentication request to the legacy system.
Legacy authentication server (LAS): a RADIUS server, LDAP server and
the like, which the AS uses to authenticate the user.
Security gateway (SGW): an IKE-speaking IPSec gateway.
The figure below presents the relations between the entities. Note
that any of the entities may be replicated for reliability, however
this document does not address possible changes in the protocol to
support such redundancy.
Sheffer, Krawczyk Internet Draft 2
PIC, A Pre-IKE Credential Provisioning Protocol March 2000
|====| |=====|
|====| AS |===| LAS |
|| |====| |=====|
|| ||
========== || (optional
| Client |===|| link)
========== || ||
|| |====|
|====| GW |
|====|
2.2 PIC Protocol Overview
The three main stages of the proposed protocol are:
- The protocol establishes a one-way trust relationship between the
client and the AS. This means that only the server is
authenticated. A secure channel from the client to the AS is
created.
- Legacy user authentication is performed over this secured channel.
The protocol we use is adopted from XAuth [3].
- The AS sends the client a (typically short-term) credential which
can be used in subsequent IKE exchanges. This credential can be
thought of as a certificate, a pair of private/public keys
generated or stored by AS, or it may also be a symmetric secret
key.
We note that the protocol proposed here is architecturally very
similar to [4]. The difference is in the details: XAuth allows more
flexibility and generality in the legacy authentication, and the
constraints of TLS and HTTP are eliminated.
2.3 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [5].
3. Assumptions and Requirements
- User authentication involves interaction with the human user and
should be made as painless as possible. In particular, multiple
authentication sessions should be avoided if at all possible.
- Legacy authentication server software cannot be changed. Neither
can we modify the authentication database. The most we can do is
add external software on the same host.
- Defense against denial-of-service attacks should be maximized at
the gateway, more so than in the AS. In many cases traffic at the
gateway is more critical than remote access, e.g. when the gateway
implements VPN functions between distant sites.
Sheffer, Krawczyk Internet Draft 3
PIC, A Pre-IKE Credential Provisioning Protocol March 2000
4. The PIC Protocol
The protocol consists of 6 messages (some of which can be repeated)
and its design follows the three logical stages presented in Sec.
2.2. Steps (1) and (2) implement the first stage (server-
authenticated key exchange between client and server), steps (3) and
(4) realize the second stage (legacy user authentication protected
with the keys derived in the first stage), steps (5) and (6) realize
the third stage (credential provisioning for successfully
authenticated users).
The first two messages are adopted from the aggressive mode with
signature authentication from [6]:
1. The Client sends: HDR, SA, KE, Ni
2. The AS sends: HDR, SA, KE, Nr, IDr1,[ CERT, ] SIG_R
Refer to Sec. 5.1 of [6] and Sec. 3 of [7] for a description of the
payloads. In particular, the key SKEYID and its derivatives SKEYID_a
and SKEYID_e are computed in the exact same way as defined in Sec. 5
of [6] for the case of signature authentication.
Messages (3) and (4) use syntax and messages similar to those of
Xauth:
3. The AS sends the first request of XAuth, encrypted using SKEYID_e
and authenticated using the negotiated prf under key SKEYID_a.
4. The Client sends the first reply of XAuth, encrypted and
authenticated as in message (3).
Steps (3) and (4) may be repeated any number of times depending on
the specific legacy user authentication method being implemented.
Note that the message pairs (2) and (3), as well as (4) and (5), are
in the same direction and may each be bundled into one message.
Alternatively, an empty ACK message can be added to simplify the
protocolĘs state.
If the user authentication is verified then the protocol proceeds to
its final stage:
5. The Client sends a credential request embedded as an XAuth
attribute: either a public key to be signed, or a request for
secret keys stored or generated at the AS.
6. The AS sends the resultant credentials embedded as a new XAuth
attribute.
Note: a reasonable alternative is to use ISAKMP payloads for steps
(5) and (6). However, this would necessitate an extension of the
ISAKMP Certificate Request payload for step (5). The current
definition of this payload means "send me your certificate" and not
"here is my public key, please sign it and return a certificate".
Sheffer, Krawczyk Internet Draft 4
PIC, A Pre-IKE Credential Provisioning Protocol March 2000
5. Protocol Security
The first two messages in the PIC protocol only provide server
authentication. Client authentication is provided during the second
stage of the protocol via the legacy user authentication mechanism in
use. The keys derived in the first stage protect the secrecy of the
user authentication. At the same time, the authentication (under
SKEYID_a) of messages (3) and (4) binds the identified user to the
keys exchanged in messages (1) and (2). Note that the client
authentication is no stronger than the legacy user authentication
mechanism in use.
The secrecy provided to the user authentication mechanism (including
user-id and password) is guaranteed even in the presence of an active
man-in-the-middle (as long as client and/or user verify the
authenticity of the serverĘs public key) and enjoys perfect forward
secrecy.
6. Legacy Authentication Techniques
All legacy authentication techniques proposed in [3] should be
supported.
7. User Credentials
This protocol can support any of the four credential schemes
described in [4]:
- Certificate for a client-generated public key
- Private/public pair generated on the server
- Provisioning of a certificate and pair of private/public keys
stored in "secure storage" at the AS
- Provisioning of a shared secret, also known to the security
gateway. Note that this requires the AS and SGW to communicate on a
regular basis, which is not required in the other methods.
8. Security Considerations
The protocol description in this initial draft lacks many details;
full specification is required for usability and security.
The Authentication Server approach involves additional security
considerations which have not been addressed in this document: they
have to do with secure storage and transmission of user credentials,
whatever form such credentials may take.
9. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
Sheffer, Krawczyk Internet Draft 5
PIC, A Pre-IKE Credential Provisioning Protocol March 2000
2 D Harkins, B Korver, D Piper, "IKE Challenge/Response for
Authenticated Cryptographic Keys", draft-harkins-ipsec-ike-crack-
00.txt (work in progress).
3 Pereira and Beaulieu, "Extended Authentication within ISAKMP/Oakley
(XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress).
4 Bellovin and Moskowitz, "Client Certificate and Key Retrieval for
IKE", draft-bellovin-ipsra-getcert-00.txt (work in progress).
5 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
6 Harkins and Carrel, "The Internet Key Exchange (IKE)", RFC 2409,
Nov. 1998.
7 Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
10.
Acknowledgments
We would like to thank Yael Dayan for her help in preparing this
document.
10. Author's Addresses
Yaron Sheffer
RADGUARD Ltd.
Atidim Technology Park, Bdg #4
61581 Tel Aviv
Israel
Email: yaronf@radguard.com
Hugo Krawczyk
Technion
32000 Haifa
Israel
Email: hugo@ee.technion.ac.il
Sheffer, Krawczyk Internet Draft 6
| PAFTECH AB 2003-2026 | 2026-04-21 08:18:51 |