Network Working Group A. Friedman Internet-Draft Technion IIT Intended status: Standards Track Y. Sheffer Expires: June 1, 2007 Check Point Ltd. A. Shaqed November 28, 2006 Short-Term Certificates draft-friedman-ike-short-term-certs-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on June 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an extension to IKEv2 that allows an endpoint to prove to a security gateway that it was already authenticated by another trusted security gateway, thereby allowing the authentication of the endpoint without user intervention. This is accomplished using a Short Term Credential that the endpoint requests from the authenticating security gateway. This credential is a certificate Friedman, et al. Expires June 1, 2007 [Page 1] Internet-Draft Short-Term Certificates November 2006 issued by the authenticating gateway for a short period of time, and it can be used to authenticate the user with IKE signature based authentication. Requirements Language 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 [RFC2119]. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Short-Term Certificate Usage . . . . . . . . . . . . . . . . . 4 4 Short-Term Certificates Issue Exchange . . . . . . . . . . . . 5 5 Using Short-Term Certificates . . . . . . . . . . . . . . . . 8 6 Expiration of Short-Term Certificates . . . . . . . . . . . . 8 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8 Security Considerations . . . . . . . . . . . . . . . . . . . 9 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Normative References . . . . . . . . . . . . . . . . . . . 9 10.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Friedman, et al. Expires June 1, 2007 [Page 2] Internet-Draft Short-Term Certificates November 2006 1 Introduction Many organizations manage one or more security gateways that provide IPsec [RFC4301] services, to allow secured connectivity between roaming endpoints and the organizational site, as well as between the organizational sites themselves. In most cases, an endpoint needs to connect to only one security gateway to gain access to internal resources. However, several situations may require an endpoint to connect to additional security gateways of the same organization. For example, this may happen when the organization manages multiple entry points to the internal network for failover, or when the endpoint needs to connect to hosts lying behind multiple security gateways. Connection to each of the security gateways requires mutual authentication between the endpoint and the security gateway. The IKEv2 Protocol [RFC4306] allows the use of legacy authentication systems along with authentications that use public key signatures and shared secrets. Legacy strong authentication systems typically require active participation of the user operating the endpoint. For example, methods using a token may require the user to enter a PIN number appearing on the token. IKE authentication methods may require such an intervention as well, e.g., entering a password to get access to a certificate file. Even if the endpoint was previously authenticated by one security gateway, any connection to an additional security gateway will require additional authentication. This document describes an extension to IKEv2 that allows an endpoint to prove to a security gateway that it was already authenticated by another trusted security gateway, thereby allowing the authentication of the endpoint without user intervention. The basic idea is to allow a security gateway to vouch for the authenticity of an endpoint, thereby saving the need for user involvement in the recurring authentication. This is accomplished using a Short Term Credential that the endpoint requests from the authenticating security gateway after the IKE SA is established. This credential is a certificate issued by the authenticating gateway for a short period of time, and it can be used to authenticate the user using IKE signature based authentication. The protocol presented here is similar in concept to the one suggested in the now expired draft of the Pre-IKE Credential Provisioning Protocol [PIC]. PIC was proposed as a form of using legacy authentication methods to enable certificate enrollment for use in IKE. While PIC is performed outside of IKE, the protocol we propose is an extension to IKEv2 used by an entity already authenticated in a former IKEV2 exchange. Friedman, et al. Expires June 1, 2007 [Page 3] Internet-Draft Short-Term Certificates November 2006 A work in progress [I-D.ohba-preauth-ps] focuses on pre- authentication in the context of EAP [RFC3748], and is mainly driven by the need to provide seamless and fast inter-technology handovers for mobile devices. In contrast, short-term certificates do not assume a common EAP server behind the gateways, and do not require gateways to communicate with each other. 2 Preliminaries The methods described in this document depend on trust between security gateways. A security gateway should be able to verify that a certificate presented by an endpoint was indeed issued by another trusted security gateway, and to establish the integrity of the presented certificate. The way this trust is established and maintained (e.g., PKI [RFC3280]) lies outside the scope of this document. 3 Short-Term Certificate Usage The use of Short-Term Certificates takes the following form: 1. At any time following a successful mutual authentication and the establishment of an IKE SA, an endpoint MAY send a request for a Short Term Certificate. 2. Subject to security gateway configuration and policy, the gateway issues a Short Term Certificate and sends it back to the endpoint. The lifetime of the Short Term Certificate will typically be the timeout until re-authentication is required. According to the IKEv2 specification, a gateway that does not support this type of request will send an empty CFG_REPLY or a response with no CFG_REPLY at all. 3. During the validity period of the certificate, the endpoint MAY use the certificate for signature-based authentication with any security gateway that trusts the issuer of the certificate, instead of using any default authentication method. Note that any security gateway that conforms to IKEv2 specification can authenticate this certificate, whether or not it conforms to the Short Term Credentials specification. The following sections describe the message exchange required for issuing a Short-Term Certificate, how the certificate is used and how expiration of a certificate should be handled. Friedman, et al. Expires June 1, 2007 [Page 4] Internet-Draft Short-Term Certificates November 2006 4 Short-Term Certificates Issue Exchange At any point after the security gateway authenticated the endpoint and the IKE SA was established, the endpoint MAY initiate a Short Term Certificate request and send it to the security gateway. A Short Term Certificate may also be requested from a security gateway which did not authenticate the endpoint directly, but authenticated it based on another Short Term Certificate (i.e., authentication with Short Term Certificates is transitive). A Short Term Certificate Request is sent as a Configuration Payload of type CFG_REQUEST in an INFORMATIONAL exchange. The reply is sent as a Configuration Payload of type CFG_REPLY in an INFORMATIONAL exchange. The following attribute types have been defined for the Short Term Certificate issue exchange: +----------------------+-------+----------------+-----------------+ | Attribute Type | Value | Request Length | Response Length | +----------------------+-------+----------------+-----------------+ | STC_CERTIFICATE_TYPE | TBD+0 | 1 octet | 1 octet | | STC_ROOT_CA | TBD+1 | 0 or more | -- | | STC_CERTREQ | TBD+2 | 0 or more | -- | | STC_CHAIN | TBD+3 | 1 octet | -- | | STC_CERTIFICATE | TBD+4 | -- | 0 or more | | STC_LIFETIME | TBD+5 | -- | 4 octets | +----------------------+-------+----------------+-----------------+ o STC_CERTIFICATE_TYPE - An encoding of a certificate type which indicates the type of certificate provided in the STC_CERTIFICATE attribute, according to the Certificate Encoding values provided for the Certificate Payload in Sec. 3.6 of IKEv2 [RFC4306] . In a request message, this field defines the encodings of all requested attributes. In a reply message, this value MUST be identical to the one appearing in the request, and MUST determine the encodings of all included attributes. For interoperability, all implementations MUST support type 1, "PKCS #7 wrapped X.509 certificate" [RFC2315]. o STC_ROOT_CA - MUST NOT be sent in a reply. An encoding identifying the Certificate Authority on whose trust chain a signature is requested. If STC_CERTIFICATE_TYPE is type 1, this field MUST contain the Binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name [ITU.X501.1993] that identifies a Certificate Authority. In a request message, one trusted Certificate Authority MAY be provided. o STC_CERTREQ - MUST NOT be sent in a reply. An encoding of a certification request, including the requesting endpoint identity, Friedman, et al. Expires June 1, 2007 [Page 5] Internet-Draft Short-Term Certificates November 2006 a public key to be associated with this identity, and a proof of possession of the matching private key. If STC_CERTIFICATE_TYPE is type 1, this field MUST contain a PKCS #10 [RFC2986] encoded certification request. o STC_CHAIN - MUST NOT be sent in a reply. A flag used to denote whether a single certificate is required (NO_CHAIN=0) or a full certificate chain (FULL_CHAIN=1). If the client already possesses the certificates required to construct a certificate chain, it may set this variable to NO_CHAIN (0) in the request message to save bandwidth. This flag is a hint: the responder MAY reply with a full chain even if no chain was requested, and vice versa. o STC_CERTIFICATE - MUST NOT be sent in a request. Whenever the request is accepted and a short term certificate is issued, the responder MUST set this attribute with an encoding of the issued certificate according to the type that appeared in the request message, and set the STC_LIFETIME attribute in accordance with the certificate contents. If STC_CERTIFICATE_TYPE is type 1, this field MUST contain a PKCS #7 encoding of the issued certificate. o STC_LIFETIME - MUST NOT be sent in a request. In the reply message, this attribute contains the remaining lifetime of the Short Term Certificate, in seconds. This value can be used by the endpoint to keep track of the Short Term Certificate expiration time, so a new certificate can be requested and the old certificate deleted by expiration. This attribute is required since the client cannot rely on the notBefore and notAfter fields supplied in the certificate: there is no guarantee that the endpoint's clock is synchronized with the security gateway's clock. In addition, the notBefore field may be set several minutes prior to certificate creation time (to compensate for minor clock deviation between security gateways). The endpoint MAY use a fixed private/public key pair for all Short Term Credential exchanges, or create a different key pair for each Short Term Certificate in use. Security considerations (see the Security Considerations section (Section 8)) may apply in case a fixed private/public key pair is used for more than one Short Term Credential exchange. In case a security gateway receives a malformed Short Term Certificate request, it MUST send a notification payload of type INVALID_SYNTAX in the response message. If the Short Term Certificate request is rejected for any other reason (e.g., gateway configuration or security policy), the gateway MUST send a notification payload of type STC_UNSUPPORTED in the response message to inform that the request was rejected. In both cases, the Friedman, et al. Expires June 1, 2007 [Page 6] Internet-Draft Short-Term Certificates November 2006 CFG_REPLY payload MUST either be sent empty or dropped altogether from the response. When a security gateway issues a Short Term Certificate, the following restrictions apply: o The Short Term Certificate MUST be a legal IKEv2 certificate, per IKEv2 [RFC4306] and PKI4IPsec [I-D.ietf-pki4ipsec-ikecert-profile]. o It is RECOMMENDED that the private/public keys used by the security gateway to issue Short Term Certificates will be different from those used for authenticating the security gateway. o The gateway MUST check that the identity appearing in the received certification request matches the identity of the endpoint associated with the IKE SA used to perform the exchange (similarly to the specification in PKI4IPsec [I-D.ietf-pki4ipsec-ikecert-profile]). In case of a mismatch, the gateway MUST reject the request. In other words, a gateway MUST NOT issue a certificate which identifies a different entity than the one associated with the IKE SA. o The gateway MUST verify the signature in the certification request, to assert that the client possesses the private key corresponding to the public key being certified. In case of an invalid signature, the gateway MUST reject the request. o The Short Term Certificate expiration time MUST NOT exceed the remaining time for repeated authentication [RFC4478], if such time is defined. If there is no defined time for repeated authentication, it is RECOMMENDED to set another short-term time constraint (setting this limit to 1 day is reasonable), which would limit the ability to abuse the Short Term Certificate. Note that IKE SA lifetime is irrelevant for determining Short Term Certificates expiration time, since rekeying IKE SAs does not require re-authentication. o If the security gateway has a signing key that was certified by the root CA described in the Short Term Certificate request, then it MUST use this key to sign the Short Term Certificate. If no signing key matches a requested root CA, then the gateway MUST reject the request. If no STC_ROOT_CA was specified in the request, the security gateway MAY choose the root CA to use. Alternatively, it MAY reject the request. o The issued certificate MUST be of the type requested in a STC_CERTIFICATE_TYPE attribute of the request message. In other Friedman, et al. Expires June 1, 2007 [Page 7] Internet-Draft Short-Term Certificates November 2006 words, the STC_CERTIFICATE_TYPE attribute has the same value in the request and the response. o The key associated with the subject of the certificate MUST be the public key sent in the Short Term Certificate request. o When a full certificate chain should be sent to the endpoint, it is RECOMMENDED to make use of "Hash and URL" formats for the certificate chain to keep message size below the maximum UDP message size supported. 5 Using Short-Term Certificates Once an endpoint acquired a Short Term Certificate from a security gateway, this certificate can be used for signature based authentication with any other security gateway that trusts the issuing gateway. Note that certificate specifications are flexible enough to allow for transferring proprietary authentication-related information from the issuing security gateway to any other security gateway which will validate the Short Term Certificate. Such proprietary extensions and their implications on security are out of the scope of this document. 6 Expiration of Short-Term Certificates An endpoint SHOULD NOT keep a Short Term Certificate after its expiration time was reached, since trying to use this certificate would result in a failed authentication. It is RECOMMENDED to refrain from using a Short Term Certificate for authentication if its expiration time is very close (e.g., less than ten minutes), since a repeated authentication [RFC4478] may take place once the newly created IKE SA is expired. When the user terminates communications with a site ("logs off"), the Short Term Credentials associated with the site MUST be destroyed. Typically this will occur in conjunction with deletion of IKE_SAs with the site. However IKE_SAs may also be deleted without explicit user action. 7 IANA Considerations The proposed extension requires IANA allocations for the "TBD" attribute types and the STC_UNSUPPORTED notify message type described in Section 4. Friedman, et al. Expires June 1, 2007 [Page 8] Internet-Draft Short-Term Certificates November 2006 8 Security Considerations Since certificates are widely used as long term credentials, special care should be taken to prevent abuse of Short Term Certificates which would lead to security risks. The expiration time of the Short Term Certificate can never be later then a time limit defined for repeated authentication. This restriction prevents the use of Short Term Credentials for artificial extension of the IKE SA validity time, bypassing actual authentication of the user. Because of the granularity of Short Term Certificates expiration time, clocks of mutually trusting security gateways SHOULD be synchronized. For example, the NTPv3 [RFC1305] or SNTPv4 [RFC2030] protocols can be implemented to provide this functionality. When such protocols are implemented to provide gateway synchronization, they MUST be properly secured to prevent attacks based on desynchronizing security gateway clocks. The Short Term Certificate issue exchange is protected with the established IKE SA. This maintains the confidentiality and the integrity of the exchange. Impersonating a security gateway would not allow a malicious user to abuse a Short Term Certificate and impersonate a valid user. Even if a malicious user was able to acquire a Short Term Certificate of another user, knowledge of the private key is still required to be able to use the Short Term Certificate successfully. Lifetime of private/public key pairs needs to be considered if the same key pair is used for more than a single Short Term Certificate exchange. The client SHOULD generate new private/public key pairs at regular intervals, in accordance with security policy. This is the same situation as applies in all Certificate Request protocols: The same private/public key pair can be used in multiple requests, but its lifetime should nonetheless be considered limited. 9 Acknowledgements 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Friedman, et al. Expires June 1, 2007 [Page 9] Internet-Draft Short-Term Certificates November 2006 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006. 10.2. Informative References [I-D.ietf-pki4ipsec-ikecert-profile] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", draft-ietf-pki4ipsec-ikecert-profile-11 (work in progress), September 2006. [I-D.ohba-preauth-ps] Ohba, Y., "EAP Pre-authentication Problem Statement", draft-ohba-preauth-ps-00 (work in progress), October 2006. [ITU.X501.1993] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1993. [PIC] Sheffer, Y., Krawczyk , H., and B. Aboba , "PIC, A Pre-IKE Credential Provisioning Protocol, Internet-draft (expired), draft-ietf-ipsra-pic-06.txt", October 2002. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Friedman, et al. Expires June 1, 2007 [Page 10] Internet-Draft Short-Term Certificates November 2006 Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Authors' Addresses Arik Friedman Technion IIT Haifa 32000 Israel Email: arikf@cs.technion.ac.il Yaron Sheffer Check Point Ltd. Ramat Gan Israel Email: yaronf@checkpoint.com Ariel Shaqed (Scolnicov) Tel Aviv Israel Email: ariel.shaqed+ietf@gmail.com Friedman, et al. Expires June 1, 2007 [Page 11] Internet-Draft Short-Term Certificates November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Friedman, et al. Expires June 1, 2007 [Page 12]