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