IP Secure Remote Access WG Y. Sheffer, Personeta Internet Draft H. Krawczyk, Technion Document: draft-ietf-ipsra-pic-02.txt B. Aboba, Microsoft Expires: December 2001 June 2001 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. Abstract This document presents a method to bootstrap IPSec authentication via an "Authentication Server" (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the legacy user authentication. Once the user is authenticated, the client machine obtains credentials 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 the EAP protocol. 1. Introduction IKE [12] provides cryptographic mechanisms to bootstrap secure IPSec associations between IP peers. However, for this IKE requires that the peers possess strong secret keys (symmetric or asymmetric). Therefore IKE does not accommodate scenarios where authentication is to be bootstrapped from a user password or other equally weak key material. Since the later form of authentication is something many commercial applications still require, the IPSRA WG of the IETF was Sheffer, Krawczyk, Aboba Internet Draft 1 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 chartered with the task to develop cryptographic mechanisms that will complement IKE by enabling the bootstrapping of IPSec secure associations based on "legacy user authentication" methods. There have been several proposals to integrate legacy authentication directly into IKE, such as [2], [3], [4]. These mechanisms define new authentication modes for IKE, an approach that is precluded by the IPSRA charter. Recently, Bellovin and Moskowitz [5] proposed an alternative approach, namely, to offload the legacy authentication task into a separate server, called an Authentication Server (AS), which upon user authentication will provide the client machine with credentials (based on strong keys) that allow for standard IKE authentication. Such a process consists of a first phase where the client machine (from which the user communicates) contacts the AS in order to receive IKE-acceptable credentials (either public key certificates or a strong shared key), and a second phase in which the client machine contacts a regular IKE/IPSec security gateway and uses these credentials in a regular IKE run for establishing secure IPSec associations. While this approach necessitates a large number of round-trips before an IPSec association is established (i.e., it involves the interaction with the AS in addition to the normal interaction under IKE), it is the most viable solution under the IPSRA requirement of not changing IKE and not adding new modes to it. This approach based on a separate AS enjoys several benefits: - 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. - Transition from a legacy-based solution implemented through a separate AS to the more scaleable and desirable PKI-based authentication supported by IKE is straightforward: just eliminate the AS phase. - A denial-of-service attack on the AS cannot compromise existing connections at the gateway (thus alleviating the damage of such attacks). - The AS may or may not be co-located with a gateway, per the organizationÆs policy. A separate AS off-loads the security gateway but may involve extra cost. - By providing a client machine with short-term credentials, a "single sign-on" approach can be supported where authentication using these credentials can be performed several times, over a short period of time, without involving repeated manual intervention by the user. The PIC protocol described in this document realizes this approach and secures it using simplified ISAKMP and IKE mechanisms. The protocol embeds Extensible Authentication Protocol (EAP) messages [6] in ISAKMP payloads to support multiple forms of legacy user authentication. Once this user authentication succeeds, the client machine obtains from the AS credentials that can be later used by the client to perform regular IKE authentication with an IPSec-enabled Sheffer, Krawczyk, Aboba Internet Draft 2 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 gateway. PIC defines several forms of credentials and can be extended to support others. Note that this document uses the term "credentials" for both digital certificates and shared secret keys. It should be emphasized that PIC 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 the secure provisioning of credentials for successfully authenticated users. The direct use of IKE, e.g. as compared to TLS tunneling [5], reduces complexity and contributes to the efficiency of the protocol. Note: EAP is a general authentication protocol, designed to allow end-points to use multiple forms of authentication. EAP does not require the server (typically a PPP or IEEE 802 end-point) to authenticate the client itself, rather it allows the server to proxy authentication messages to a back-end authentication server, and inspect the packets to determine if the authentication was successful. The reader is referred to [6] for more details on EAP. 1.1. Protocol Entities User: the human being at the client machine. Client: a client machine which communicates with the authentication server and 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 (GW): an IKE-enabled IPSec gateway. The figure below presents the relations between the entities. Note that any of the entities may be replicated for reliability. Such redundancy mechanisms are outside the scope of this document. Sheffer, Krawczyk, Aboba Internet Draft 3 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 |====| |=====| |====| AS |=====| LAS | || |====| || |=====| || || || || || || |====| || || |== (Optional) ===| CA | || || |====| || || ========== || (optional | Client |===|| link) ========== || || || |====| |====| GW | |====| The PIC protocol is defined between the Client and the AS. All other exchanges between the entities are implicit in the protocol and not defined here. This applies in particular to legacy authentication between AS and LAS, and certification between AS and the CA. 1.2. PIC Protocol Overview The three main stages of the proposed protocol are: 1. The protocol establishes a one-way authenticated channel from the client to the AS in which only the server is authenticated. 2. Legacy user authentication is performed over this secured channel. Legacy authentication information is transported using EAP [6] tunneled within ISAKMP. 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 private key generated or stored by the AS and accompanied by a corresponding certificate, or it may also be a symmetric secret key. To minimize the number of messages exchanged in PIC, the different stages share messages, and the protocol takes care to ensure security of the third stage despite the fact that it is started while the client is not yet authenticated. 1.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 [7]. 1.4. Change Log -00: Initial version, schematic. -01: Much more detail, changed XAuth to EAP. -02: Added rationale sections. Modified hash computation, eliminated payload encryption in message (2), added section on retransmission. Sheffer, Krawczyk, Aboba Internet Draft 4 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 2. Assumptions and Requirements The basic underlying requirements and assumptions in PICÆs design are as follows (derived from the IPSRA WG set of requirements). - The legacy authentication server software and database cannot be modified. They can only be accessed in a "black-box" way according to the existing interface (e.g., one cannot retrieve a userÆs password stored in such a database). - It is assumed that the Client possesses (e.g. by pre-configuration) the public key of the AS, or it has the means to obtain and validate a certificate for the AS (e.g., by pre-configuration of a CA public key). - No secret key is assumed at the client beyond legacy user authentication material (password). In particular, "machine authentication" is not supported. - The protocol should not require any changes to IKE or to security gateways that support standard IKE and IPSec. - The protocol should provide a solution that supports easy transition to certificate-based authentication. - 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. 3. PIC and ISAKMP PIC is based on ISAKMP [13] and the ISAKMP IPSec DOI [8], with a few minor additions. The SA created during the first exchange of PIC MUST NOT be used for any messages other than the PIC messages described here. The SA MUST be destroyed when the PIC exchange is concluded. 3.1. The PIC Exchange PIC defines a new ISAKMP exchange. The ISAKMP Exchange Type for PIC is 250. 3.2. The PIC Transform PIC defines a new Transform Identifier, KEY_PIC, for the Proposal payload, since KEY_IKE implies mutual authentication while PIC only provides unilateral authentication during the first exchange. The value of KEY_PIC is 2. Sheffer, Krawczyk, Aboba Internet Draft 5 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 3.3. ISAKMP Message ID The Message ID field in the ISAKMP header must be 0 for all PIC messages. This is similar to phase 1 exchanges. 3.4. Protection of Payloads The new ISAKMP payloads defined below are protected in two different ways: - In the second message of the protocol, the EAP payloads are integrity-protected but not encrypted. - In all the following messages, the entire message is encrypted. In both cases, a MAC is computed over the plaintext payloads. This special processing of the second message results from our desire to stay within the current framework of ISAKMP processing, while reducing the protocolÆs number of messages to the minimum. See Sec. 5.1 for a justification of the lack of confidentiality-protection in message (2). 3.5. Informational Exchanges and Payloads ISAKMP Informational exchanges are allowed at any point during PIC. Notification and Vendor ID payloads may be inserted at any point following the HASH payload in PIC messages. There are no new Notify payloads defined in PIC. 4. The PIC Protocol 4.1. Transport The PIC protocol is an ISAKMP exchange. It inherits the following properties from ISAKMP: - UDP transport. - Use of port 500. See Sec. 4.5 regarding retransmission policy. At the time of writing, the issues of NAT traversal are still unresolved in the context of IKE and IPSec. PIC will adopt whatever decision is taken for IKE. In the meantime, the server MUST listen on port 500. The server SHOULD NOT assume the source port on PIC messages is 500, and SHOULD use the source port number for its replies. Implementation note: stage 2 of PIC involves manual password entry. Retransmission timeouts should allow for human speeds. Sheffer, Krawczyk, Aboba Internet Draft 6 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 4.2. ISAKMP Payloads PIC defines several new payloads: - EAP û to embed EAP messages within ISAKMP. - CREDENTIAL-REQUEST û allows the client to request a credential. - CREDENTIAL û allows the AS to return a credential. The following defines each of the payloads. 4.2.1. The EAP Payload The EAP payload is defined to embed EAP messages. Its payload type is 201. Its format is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Sequence ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ EAP Message ~ ! ! +++++++++++++++++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The EAP Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, must be 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, the transaction- specific header and the embedded message. If the length does not match the length of the payload headers plus the embedded message, then the entire payload MUST be discarded. o Sequence (1 octet) - a sequence number of EAP payloads in the current exchange, starting at 1. The number is incremented for each EAP payload when multiple payloads occur in a single message. Such multiple payloads MUST be ordered within the ISAKMP message according to their sequence number. A single payload sequence is maintained between the Client and Server. o RESERVED (3 octets) - Unused, must be 0. o EAP Message - An EAP message as defined in [6], including any later additions to the standard. Sheffer, Krawczyk, Aboba Internet Draft 7 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 4.2.2. The CREDENTIAL-REQUEST Payload The CREDENTIAL-REQUEST payload is defined to allow the client to request a credential. Its payload type is 202. Its format is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! Subtype ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Type-Specific Information ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, must be 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, the transaction- specific header and any additional information. If the length does not match the length of the payload headers plus additional information, then the entire payload MUST be discarded. o Type (1 octet) - denotes the type of credential. Values are: 0: None. 1: The Client provides a public key and a certificate request for that key. The AS responds with a certificate for the Client. 2: The AS provides a pair of private key and certificate for the client. 3: The AS provides a shared secret. This type is reserved for future use. 4..127: Reserved for future versions. 128..255: Reserved for private use. The value None MUST NOT be sent. o Subtype (1 octet) - denotes a specific type of certificate. This is only applicable when the Type field is 1 or 2. Otherwise, the value is 0. Values are as defined in the ISAKMP CERTIFICATE payload (Sec. 3.9 of [13]). The value None MUST NOT be sent. o RESERVED (2 octets) - Unused, must be 0. Sheffer, Krawczyk, Aboba Internet Draft 8 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 o Type-Specific Information: this is a variable field, whose contents depend on the Type and Subtype fields. This version of the protocol defines the contents for 3 cases only. For Type 1 with Subtype 1 (PKCS #7 wrapped X.509 certificate): this field contains a certificate request in PKCS #10 [9] format (CertificationRequest). The receiver MUST verify correctness of the "signature" component, which proves possession of the private key corresponding to the public key being certified. For Type 1 with Subtype 4 (X.509 Certificate - Signature): this field contains a certificate request in PKCS #10 [9] format (CertificationRequest). The receiver MUST verify correctness of the "signature" component, which proves possession of the private key corresponding to the public key being certified. For Type 2 with Subtype 4, this field is omitted. All other Type-Subtype combinations are undefined. They MUST NOT be sent, and MUST be rejected if received. 4.2.3. The CREDENTIAL Payload The CREDENTIAL payload is defined to allow the AS to send various types of credentials. Its payload type is 203. Its format is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! Subtype ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Type-Specific Information ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, must be 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, the transaction- specific header and any additional information. If the length does not match the length of the payload headers plus additional information, then the entire payload MUST be discarded. o Type (1 octet) - denotes the type of credential. Values are as defined for the CREDENTIAL-REQUEST payload. Sheffer, Krawczyk, Aboba Internet Draft 9 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 The value None means that a credential according to the ClientÆs request is not available. The entire PIC exchange is failed, and any further behavior is outside the scope of this document. Reserved values MUST be rejected by the receiver. o Subtype (1 octet) - denotes a specific type of certificate. This is only applicable when the Type field is 1 or 2. Otherwise, the value is 0. Values are as defined in the ISAKMP CERTIFICATE payload (Sec. 3.9 of [13]). o RESERVED (2 octets) - Unused, must be 0. o Type-Specific Information: this is a variable field, whose contents depend on the Type and Subtype fields. This version of the protocol defines the contents for 3 cases only. For Type 1 with Subtype 1 (PKCS #7 wrapped X.509 certificate): this field contains a certificate or certificate chain in PKCS#7 [10] format. For Type 1 with Subtype 4 (X.509 Certificate - Signature): this field contains an X.509 certificate. For Type 2 with Subtype 4, the Information field contains a private key and corresponding certificate, wrapped in a PKCS #12 [11] PFX PDU. All other Type-Subtype combinations are undefined. They MUST NOT be sent, and MUST be rejected if received. Note: for Type option 2, it is up to the serverÆs local policy to decide whether a certificate is fetched from storage or generated from new material. 4.3. Protocol Notation As in ISAKMP, '*' signifies payload encryption after the ISAKMP header. This encryption MUST begin immediately after the ISAKMP header and all payloads following the ISAKMP header MUST be encrypted. As in ISAKMP, payload_b denotes the base payload, stripped of its generic ISAKMP header. EAP(i) denotes the i'th EAP payload in a message, counting from payload 1. Note that this is different from the EAP payloadÆs Sequence field, which is incremented across messages. Sheffer, Krawczyk, Aboba Internet Draft 10 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 4.4. Protocol Exchanges The protocol consists of a variable number of messages, with a minimum of 4 messages. 4.4.1. Messages (1) and (2) The first two messages are adopted from IKE Aggressive Mode with Signature Authentication: Client AS ------ -- (1) HDR, SA, KE, Ni [, IDii] ==> (2) <== HDR, SA, KE, Nr, IDir,[ CERT, ] SIG_R, HASH, EAP [, EAP...] These two messages establish the PIC SA, for all the following messages. The EAP payloads in message (2) are not encrypted, as explained in Sec. 5.1, however, they are integrity-protected. Refer to Sec. 5.1 of [12] and Sec. 3 of [13] for a description of the payloads. The value SKEYID and its derivatives SKEYID_a, SKEYID_d and SKEYID_e are computed in the exact same way as defined in Sec. 5 of [12] for the case of signature authentication. Similarly for the Initialization Vector (IV), when applicable. SA encryption keying material is derived as in [12], Appendix B. Note that SKYID_d is discarded after the other derived keys are computed. The Transform Identifier in the SA payloads MUST be KEY_PIC. The Authentication Method in the SA payload MUST be RSA Signatures or DSS Signatures. Proposal negotiation takes place as in [12], for Phase 1. Payloads are ordered as in Sec. 5 of [12], for Aggressive Mode with Signatures. There are no additional constraints on the order of the HASH and EAP payloads. SIG_R is derived from HASH_R, as in [12]. HASH_R is computed differently in PIC, to correct a typo in [12], and to protect fields sent by the Client. The responderÆs SA payload is used in the calculation: HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAr_b | SAi_b | IDir_b | [| IDii_b]) IDii MUST be included in HASH_R if it was sent by the Client. The Client MUST validate the correctness of the SIG_R payload. If a certificate is transmitted, the Client MUST verify that it is trusted. Sheffer, Krawczyk, Aboba Internet Draft 11 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 Message (2) MUST contain one or more EAP payloads. The HASH payload is calculated over the ISAKMP cookies, and the concatenated (plaintext) EAP payloads: HASH = prf(SKEYID_a, CKY-I | CKY-R | EAP(1)_b | EAP(2)_b...) The HASH may differ from the illustration above if any optional payloads, for example a notify payload, have been chained to the message. In such cases the HASH MUST include all such payloads, and in the order they appear, possibly interleaved with the EAP payloads. HASH is computed over all optional payloads following SIG_R. 4.4.2. Messages (3) and (4) Messages (3) and (4) may be repeated as required by the legacy authentication method, alternating between the Client and the AS, that is, message (3) is always followed by message (4). Client AS ------ -- (3) HDR*, HASH, EAP, [EAP...,] ==> [CREDENTIAL-REQUEST] (4) <== HDR*, HASH, EAP, [EAP...,] [CREDENTIAL] [Repeat of message (3) ==> <== Repeat of message 4]... Both Client and AS MUST verify correctness of the Sequence field in each received EAP payload. This is to prevent replay or reordering of these payloads. The Sequence numbers should be strictly consecutive from one EAP payload to the next, within and across PIC messages. If an IDii payload was sent by the Client in message (1), the AS SHOULD match it against a Response/Identity EAP message, if one is received. This document does not specify the mapping between the two identities. The last EAP payload sent by the AS MUST be a Success or a Failure message, in the sense of [6]. A CREDENTIAL-REQUEST payload MUST be sent exactly once, in the first message (3) sent by the Client. A CREDENTIAL payload MUST be sent exactly once, in the last message sent by the AS. The Server SHOULD NOT process the CREDENTIAL-REQUEST before the Client completes its authentication, i.e. just before the AS sends the EAP Success message. This is to protect against denial of service by a yet-unauthenticated client. Sheffer, Krawczyk, Aboba Internet Draft 12 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 The protocol does not define how the AS produces the CREDENTIAL payload, whether internally, in cooperation with a gateway or with a CA. However, the Type/Subtype combination for the CREDENTIAL MUST be the same as in the CREDENTIAL-REQUEST, unless the Type returned is None (no credential is available). The HASH payload is defined over the ISAKMP cookies and the concatenated payloads: HASH = prf(SKEYID_a, CKY-I | CKY-R | EAP(n)_b | EAP(n+1)_b... [| CREDENTIAL-REQUEST_b] [| CREDENTIAL_b]) The HASH may differ from the illustration above if any optional payloads, for example a notify payload, have been chained to the message. In such cases the HASH MUST include all such payloads, and in the order they appear, possibly interleaved with the EAP payloads. The HASH payload for each message MUST be checked by each recipient. Each of messages 3 and 4 MUST NOT be repeated more than 10 times (not counting retransmissions). 4.5. Retransmission policy In EAP, as described in [6], the server (also known as the ôauthenticatorö) sends EAP-Request messages and the peer sends EAP- Response messages. In EAP, the server is responsible for retransmission. Section 2.2.1 of [6] states: "Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests... Responses MUST only be sent in reply to a received Request and never retransmitted on a timer." Section 2.2 states: "If a peer receives a duplicate Request for which it has already sent a Response, it MUST resend its Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request." Section 2.2.2 states: "Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure." Sheffer, Krawczyk, Aboba Internet Draft 13 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 Thus, if an EAP-Response message is not received by the server, then the corresponding EAP-Request message is retransmitted. It does not matter whether the problem was caused by loss of the EAP-Request or EAP-Response. The exception is EAP-Success and EAP-Failure messages, which are not acknowledged. Given this retransmission policy, it is possible for EAP peers and servers to receive duplicate messages. However, messages are never received out of order; EAP is an ACK-NAK protocol so that only a single packet is in flight at a time. Thus reordering is not possible. ISAKMP has its own (contradictory) retransmission policy. [13] Section 5.1 states: "When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Set a timer and initialize a retry counter. NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based on measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff). 2. If the timer expires, the ISAKMP message is resent and the retry counter is decremented. 3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file. 4. The ISAKMP protocol machine clears all states and returns to IDLE." Section 3.1 states: "NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase 2 SA negotiation message following a Phase 1 exchange or encrypted traffic following a Phase 2 exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the received message (i.e. Phase 2 SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final message. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established." Note that while [13] states that retransmission timers should be adjusted dynamically, it does not define the algorithms that provide for this. As a result, when EAP is run over ISAKMP, it is possible Sheffer, Krawczyk, Aboba Internet Draft 14 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 for both EAP-Request and EAP-Response messages to be retransmitted, in contradiction to [6]. For example, if an EAP-Request packet is lost, the sequence of events is as follows: a. The server ISAKMP will retransmit the EAP-Response message after expiry of its retransmission timer. b. Depending on the round-trip time, the retransmitted EAP-Response may not arrive in time to prevent the peer ISAKMP from retransmitting the EAP-Request message after expiry of its retransmission timer. c. The server EAP will retransmit the corresponding EAP-Response packet. d. The peer EAP will retransmit the EAP-Request message in response to the (multiple) EAP-Response retransmissions. Thus, the potential exists for high-gain multiplication of retransmissions precisely at the time when congestive losses are most likely. Thus, running EAP over ISAKMP as specified in [13] has the potential to be congestion-unfriendly. To understand the circumstances under which this will occur, it is worthwhile to examine the retransmission timeline in more detail, as seen from the PeerÆs point of view. Time Peer Server ------ ---- ------ 0 EAP-Response1 -----------> OTTps + TsR EAP-Request2 <----------- --- Request Lost --- RTOp EAP-Response1 ------------> OTTps + TsR + RTOs EAP-Request2 <------------ OTTps + TsR + RTOp EAP-Request2 <------------ OTTps + TsR + RTOs + OTTsp + TpR EAP-Response2 ------------> OTTps + TsR + RTOp + OTTsp + TpR EAP-Response2 ------------> Sheffer, Krawczyk, Aboba Internet Draft 15 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 Key --- OTT = One-way Trip Time OTTps = One-way trip time (Peer to Server) OTTsp = One-way trip time (Server to Peer) RTOp = Peer Roundtrip TimeOut RTOs = Server Roundtrip TimeOut TdA = Delayed ACK timer TpR = Peer Response processing time TsR = Server Request processing time RTTps = OTTps + OTTsp As described above, the Peer retransmits the EAP-Response after expiration of its Round-Trip Timeout (RTO). At roughly the same time that the retransmitted Response is arriving, the ServerÆs own RTO timer will expire. This makes it possible for the Server to send duplicate EAP-Requests, in response to which the peer may send duplicate EAP-Responses. Thus, in response to 1 lost packet, 3 packets are sent within OTTps + TsR. This violates the law of conservation of packets. To address this issue, it is recommended that the interface between EAP and ISAKMP be structured so that ISAKMP appears to provide a reliable transport mechanism to EAP. That is, ISAKMP should provide EAP with a reliable, non-duplicated stream of packets. If EAPÆs retransmission timers are adjusted so as to always be longer than the ISAKMP timers, then EAP-driven retransmission will never occur. Also, if ISAKMP does not provide EAP with duplicates, then duplicate-driven retransmissions will not occur. In the illustration above, the retransmitted EAP-Response1 packet MUST NOT be provided to the EAP layer on the server, since EAP-Response retransmissions are prohibited within EAP. This will eliminate the duplicate EAP- Response2 packets, as well as the duplicate EAP-Response2 packets. Thus, the retransmission gain will be reduced from 3 to 2. Even better would be to ensure that the RTOp is always substantially larger than RTOs. For example, RTOp could have an RTOmin of 2 seconds, while RTOmin for RTOs could be 1 second. If this were done, then the retransmission of EAP-Request2 will be likely to arrive prior to expiration of the retransmission timer for EAP-Response1, canceling the retransmission. This would reduce the retransmission gain to 1, satisfying the law of conservation of packets. 5. Design Considerations In this section we discuss several design considerations behind the specification of PIC. This discussion is intended for analysis and clarification and does not contain further protocol specification or implementation details. Sheffer, Krawczyk, Aboba Internet Draft 16 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 5.1. Protocol Security As outlined in Sec. 1.2, PIC consists of three logical stages. The first stage, establishment of a key between client and AS with authentication by AS only, is carried out in messages (1) and (2). The second stage, authentication of the client using legacy authentication, is accomplished via the information carried in the EAP payloads of messages (2), (3) and (4). The third stage, request and delivery of client's certificate, is carried via the credential payloads in messages (3) and (4). This multi-functionality of messages (2), (3) and (4) is done in order to save round trips between the parties. AS authentication is done via the use of the server's public key (which is assumed to be known to, or verifiable by, the client) and then is as secure as the underlying signature algorithm and security parameters (such as key length). This authentication provides a guarantee for the client that it is safe to send the user- authentication data in the second stage encrypted under the (server- authenticated) SKEYID_e key which is derived from the exchange in the first stage. Thus, protection of the user's authentication data is provided against eavesdroppers as well as against active intruders that try to impersonate the AS. Moreover, the authentication of the client's data under SKEYID_a in the second stage binds the authenticity of the client to the first stage too. Finally, encryption and authentication under SKEYID_e and SKEYID_a, respectively, protect the secrecy and integrity of the credentials information exchanged between client and AS in the third stage. Since the exchange in the first stage is protected with perfect forward secrecy (via Diffie-Hellman), all the encrypted data in the protocol (including user's authentication data) is protected against key compromise as soon as the SKEYID key, and its derived keys, are safely erased from memory. We note, however, that the EAP payloads transmitted from AS to client before the successful authentication of the client is verified cannot be considered protected by the encryption under SKEYID_e. This is so since a spoofing client can participate in the first stage, compute SKEYID_e, and decrypt the information sent by the AS. Therefore, the AS MUST NOT include confidential information in these payloads. Moreover, note that the EAP payloads piggybacked to message (2) are NOT ENCRYPTED at all. This design decision simplifies the specification and processing of message (2) while, by the above argument, it does not compromise security. However, this means that PIC does not hide the AS identity and it does not secure legacy- authentication mechanisms that require confidentiality of the initial data sent from AS to client (e.g., an authentication challenge). Reasonably secure user-authentication mechanisms should not be affected by the latter. Sheffer, Krawczyk, Aboba Internet Draft 17 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 In practice, EAP payloads in message (2) will contain an EAP Request/Identity message, which typically does not require any protection. Another design decision in PIC that is worth a clarification is the authentication of the SA proposal sent in message (1) from client to AS. Note that in the signature mode of IKE this information is authenticated via HASH_I and the initiator's signature. However such a signature is not present in PIC. The solution adopted here is to include this information (SAi_b) under the AS signature (HASH_R). In this way, any change of the SAi information in its way from Client to AS will be detected by the client upon verification of HASH_R. We remark on the order of encryption and authentication as applied in PIC. Recent results show that in order for encryption functions to really provide secrecy protection against active attackers (as required in the PIC's scenario) the ciphertext needs to be authenticated via a secure MAC. As it turns out, computing the MAC on the plaintext and encrypting the plaintext and MAC does not provide, in general, a sufficient guarantee of secrecy [14]. This calls for protocols, in particular PIC, to adopt the encrypt-then-authenticate approach in which the authenticating MAC is applied to the ciphertext rather than to the plaintext. However, in order to apply this safer method in PIC one has to change the regular processing of ISAKMP which applies encryption via the HDR* convention, namely, all information after the header is encrypted including the HASH (or MAC) payload. Since, on the other hand, it is also shown in [14] that this order of processing is secure under the specific use of standard CBC or stream-cipher encryption, PIC's design decision has been to favor the currently deployed ISAKMP processing at the expense of sacrificing the robustness of the protocol to future changes in cryptographic algorithms. This means that any future change to the protocol that affects the way encryption and MAC-generation is done will require much care and renewed analysis. Another design decision made in order not to change the regular ISAKMP processing is to apply authentication (under the HASH payload) to base payloads only and not to payload headers. Authenticating all bits, including headers, would have been a better approach but also in this case we have favored ISAKMP compatibility. 5.2. Design Choices Some of the design decisions that were made in developing this protocol are: - ISAKMP-based to reuse ISAKMP implementation. - Transport of legacy authentication via an already standardized protocol: EAP. - Negotiation is kept to a minimum for simplicity. - Reducing the number of messages via piggybacking. - AS may or may not be decoupled from the gateway. Sheffer, Krawczyk, Aboba Internet Draft 18 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 - Client is assumed to be pre-configured with the address of the AS, as well as the security gateway. - Full trust in AS. - Short-term certificate avoids the need for human intervention if a SA needs to be re-established ("single sign-on"). - Server-side key generation and key storage have been merged into a single credential-request type. The choice of method is left to AS policy. 5.3. Legacy Authentication Legacy authentication may be performed by the Authentication Server or may be proxied by it to a legacy server. The protocol allows for several types of authentication to be tried by the Server before it decides that it cannot authenticate the Client. We note that EAP specifies that any implementation MUST implement MD5-Challenge as an authentication method. EAP does not support cleartext authentication mechanisms, such as PAP. 5.4. Credentials and Negotiation The protocol as described requires the policies of Client and Server to match regarding credentials. For example, an unrecoverable protocol error results if the Client is unable to produce a private key but the server requires this capability. Several approaches for credential negotiation were considered and rejected for this protocol, in the interest of simplicity. The general case would require negotiation of multiple properties in parallel, for example: - Is the private key generated by the Client or the AS. - What type of certificate is required, in particular which algorithm. - What length of keys is required, for each of the credentialÆs components. 5.5. Round Complexity PIC as defined in this document acts as a front-end protocol to IKE. It requires several round trips (two at least) to obtain credentials from the AS, and then the additional round trips of IKEÆs phase 1 and 2 are needed to complete the establishment of an IPSec association. Therefore, an obvious criticism to PIC is the high number of communication rounds required from the moment a client contacts the AS until the time in which the IPSec association is finally established. This communication cost, however, is unavoidable given the IPSRA set of requirements. For completeness, and for possible future use, we outline here some ways in which PIC itself can be adapted (and simplified) to provide a more efficient way of IPSec bootstrapping based on legacy user authentication. Sheffer, Krawczyk, Aboba Internet Draft 19 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 One option is to eliminate the authentication server (AS), and run PIC, without the third stage of credential retrieval, directly against an IKE/IPSec security gateway as a phase 1 authentication mode of IKE. The derived SKEYID_a/d/e will then be used as in a regular phase 2 exchange in IKE. This means that such a gateway would be required to support a modified IKE which includes such a new mode of phase 1 authentication. (As explained in the introduction this approach is currently precluded by the IPSRA charter.) Moreover, this gateway will be required to support interaction with the legacy authentication system (which adds to the complexity of the gateway, and presents additional opportunities for denial of service attacks). An alternative to the above is to keep the AS, run PIC without its third stage against the AS (which will be responsible to verify the userÆs authentication), and pass the resultant SKEYID key from the AS to the gateway. Now the client could contact the security gateway and run phase 2 of IKE based on this value of SKEYID. This requires secure communication between AS and the gateway, as well as a modification of IKE to support a direct phase-2 authentication mode. 5.6. Other Extensions PIC does not support machine authentication. However, we note here that if such extension to PIC is desirable at some point, then it is possible to add this functionality if one assumes the machine to possess a private signing key and a certificate that can be validated by the AS. In this case, one would add to PIC a message from client to AS, after the current message (2), similar to the third message of IKEÆs aggressive signature mode, in which the signature would be computed using the machineÆs signature key. It should be noted that this solution involves some hidden complexity (the server needs to make policy decisions with only partial information regarding the client's identity). One way around this problem is to add a second ID payload to message (1) from the Client. Another functionality not provided by PIC is authentication based on a shared password between user and AS, and without relying on an AS public key. Such functionality can be provided using mechanisms such as EKE [ADDREF15]. However, this would require a completely new protocol; only the third stage (credential provision) of PIC could be reused. Moreover, since there is to date very little deployment of password-based scheme such as EKE, this would fall outside of the IPSRA charter which is to leverage legacy authentication methods. 6. Security Considerations This entire document discusses a protocol for the provisioning of security-critical information. The Authentication Server approach involves additional security considerations which are beyond the scope of this document: they have to do with secure storage of user credentials, and secure Sheffer, Krawczyk, Aboba Internet Draft 20 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 communication with other (optional) entities, the CA, legacy authentication server and gateway. The Client is typically the less protected peer. Thus, when Type 1 credentials are used, the Client SHOULD generate a fresh key pair on each PIC exchange. The PIC protocol authenticates the human user. There is no attempt to authenticate the machine from which the user is connecting. Thus the AS is unable to make policy decisions according to the security of the client machine. Moreover, PIC, just like IKE and IPSec, should only be used on a physically secure client machine. Once the first exchange of the protocol is complete, the Client has authenticated the AS and has full trust of the AS, for the purposes of credential provisioning. Thus it is not required to validate the credential it receives. Note that in some cases the Client cannot validate the credential. See Sec. 5 for some of the rationale that drove the security design of the protocol. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Pereira and Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress). 3 D Harkins, B Korver, D Piper, "IKE Challenge/Response for Authenticated Cryptographic Keys", draft-harkins-ipsec-ike-crack- 00.txt (work in progress). 4 Litvin, Shamir, Zegman, "A Hybrid Authentication Mode for IKE", draft-zegman-ike-hybrid-auth-00.txt (work in progress). 5 Bellovin and Moskowitz, "Client Certificate and Key Retrieval for IKE", draft-bellovin-ipsra-getcert-00.txt (work in progress). 6 Blunk and Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, Nov. 1998. 9 Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998. Sheffer, Krawczyk, Aboba Internet Draft 21 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 10 B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version 1.5", RFC 2315, March 1998. 11 RSA Security Inc., "PKCS #12: Personal Information Exchange Syntax Standard", http://www.rsalabs.com/pkcs/pkcs-12/. 12 Harkins and Carrel, "The Internet Key Exchange (IKE)", RFC 2409, Nov. 1998. 13 Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. 14 Krawczyk, H., "The order of encryption and authentication for protecting communications (Or: how secure is SSL?)", CRYPTO 2001 Proceedings. Full version in: Cryptology ePrint Archive, http://eprint.iacr.org/2001/045 15 S.Bellovin and M.Merritt, "Augmented encrypted key exchange: a password-based protocol secure against dictionary attacks and password-file compromise," Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 244-250, 1993. 8. Acknowledgements We would like to thank Yael Dayan for her help in preparing this document, and Udi Arie and Scott G. Kelly for reviewing an early version. 9. IANA Considerations The following values will need to be re-allocated as the protocol progresses to a standard. - ISAKMP Exchange - ISAKMP Transform Identifier (Sec. 4.4.2 of [8]) - Next Payload identifiers 10. AuthorsÆ Addresses Yaron Sheffer Personeta 1 HaNagar St. 45241 Hod HaSharon Israel Email: yaronf@personeta.com Sheffer, Krawczyk, Aboba Internet Draft 22 PIC, A Pre-IKE Credential Provisioning Protocol June 2001 Hugo Krawczyk Dept. of Electrical Engineering Technion 32000 Haifa Israel Email: hugo@ee.technion.ac.il Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: bernarda@microsoft.com Sheffer, Krawczyk, Aboba Internet Draft 23