TOC 
Network Working GroupY. Sheffer
Internet-DraftCheck Point
Intended status: InformationalMarch 01, 2010
Expires: September 2, 2010 


Password-Based Authentication in IKEv2: Selection Criteria and Comparison
draft-sheffer-ipsecme-pake-criteria-00.txt

Abstract

The IPsecME working group has been chartered with specifying a new password-based authentication method for IKEv2. This document presents a few solution alternatives, and lists potential criteria for choosing among them. It is not the author's intention to publish this document as an RFC. Moreover, it is more subjective than most IETF documents.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 2, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



Table of Contents

1.  Introduction
2.  Terminology
3.  Selection Criteria
    3.1.  Security Criteria
    3.2.  Intellectual Property
    3.3.  Other Considerations
4.  Some Possible Candidates
5.  Comparison Table
6.  IANA Considerations
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Change Log
    A.1.  draft-sheffer-ipsecme-pake-criteria-00
§  Author's Address




 TOC 

1.  Introduction

The new IPsecME WG charter defines a new work item on password-based authentication for IKEv2. This is a somewhat contentious issue, so the charter is very particular about the requirements. Quoting in full:

IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for "strong" shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server.

However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for "weak" shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations.

The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed.

The charter defines some properties that a good solution is required to have. For example, despite the fact that EAP is an integral part of IKEv2, there are good reasons to avoid it in this case. But the charter does not name a specific cryptographic protocol on which to base this solution, nor does it mention a specific IETF document as a starting point. This document asserts that several such choices are possible, and attempts to provide the group with some selection criteria, in order to enable a reasoned discussion of these (and possibly other) alternatives.



 TOC 

2.  Terminology

This document is entirely non-normative. None of the IETF-capitalized words SHOULD be used, and if perchance they are, they MUST be ignored.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Selection Criteria

IKEv2 is targeted at applications that require a very high level of security. Therefore, adding a new mode of operation to the protocol can only be done after careful consideration. In this section, I describe some of the criteria we can use to choose between solution candidates. Unfortunately, I am not aware of any potential solution that score a "perfect 10" under these criteria. If this paper encourages the development of new solutions that better fit the criteria, so much the better.



 TOC 

3.1.  Security Criteria

The primary requirement from a good solution is to have a high level of security. Unfortunately, we all know this property is extremely hard to gauge. But some data might enhance our confidence in a solution's security.



 TOC 

3.2.  Intellectual Property

"Intellectual property", a common euphemism for patents, is a complex issue. The existence of patents covering a specific technology is often an important consideration for vendors, and critical for open source implementers. Despite this fact, the IETF does not provide its constituency with any legal guidance or assistance in this matter.

Unfortunately, the specific area of password-based authentication is riddled with patents. This has hampered the IETF adoption of this technology for years, and caused at least one working group to fail. As a result, we (as individual implementers and as a working group) need to understand as best we can the IPR status of each proposal.

Disclaimer: I am not a lawyer, and this document should not be construed as legal advice.

IETF rules require that any participant who's aware of a patent relevant to an IETF work item should disclose the patent's existence. In practice, such disclosures are often submitted very late in the process, resulting in a long period when a document's IPR status remains unclear. Even more worryingly, in at least one case I am aware of, a company filed an IPR statement for a competitive technology asserting their own patent, even though the technology is in fact covered by another patent, making it very likely that the company's patent does not apply to the technology. Given this background, I propose the following as selection criteria:



 TOC 

3.3.  Other Considerations

A few additional criteria may be just as important:



 TOC 

4.  Some Possible Candidates

This section provides background regarding some of the candidate protocols. Some pertinent properties are mentioned, but this is by no means an analysis against the criteria defined above.

  1. EKE is the oldest password-authenticated key exchange (PAKE) protocol still considered secure, although some of its variants have been broken. It is covered by a patent, due to expire in late 2011.
  2. SPSK (a.k.a. EAP-PWD) is a relatively new mechanism. It has been standardized within IEEE 802.11s.
  3. PAK is the earliest provably-secure mechanism. A protocol description has been standardized within the IETF, but no other IETF PAK-based protocol exists. PAK is patented (IPR statement #1179).
  4. SRP has been deployed in multiple products. It is described by several IETF documents, including a TLS-SRP variant. SRP can be used under a royalty-free license.

In addition, applicable standards to be consulted for these and additional protocols include:



 TOC 

5.  Comparison Table

This is a very rough attempt at a comparative analysis. Many of the details are incomplete, and/or controversial.

NameStandardsSecurity AnalysisIPR
EKE [I‑D.sheffer‑emu‑eap‑eke] (Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, “An EAP Authentication Method Based on the EKE Protocol,” April 2010.) Well analyzed security, since 1992, several analysis papers published. Patent from 1992 (Lucent?), due to expire Oct. 2011.
SRP SRP published as [RFC2945] (Wu, T., “The SRP Authentication and Key Exchange System,” September 2000.), TLS-SRP is [RFC5054] (Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, “Using the Secure Remote Password (SRP) Protocol for TLS Authentication,” November 2007.). IEEE 1363.2. Published and unpublished analysis by Bleichenbacher. Patent held by Stanford University, with a free license. Phoenix posted an IPR statement, but no request for reexamination.
SPSK [I‑D.harkins‑emu‑eap‑pwd] (Harkins, D. and G. Zorn, “EAP Authentication Using Only A Password,” April 2010.), [I‑D.harkins‑ipsecme‑spsk‑auth] (Harkins, D., “Secure PSK Authentication for IKE,” March 2010.). Security analysis by NIST cryptographers. Explictly not patented. May or may not infringe on existing patents.
SPEKE IEEE 1363.2. [To be completed] Patents held by Phoenix.
PAK Published as [RFC5683] (Brusilovsky, A., Faynberg, I., Zeltsan, Z., and S. Patel, “Password-Authenticated Key (PAK) Diffie-Hellman Exchange,” February 2010.). IEEE 1363.2. [To be completed] Patents held by Lucent.



 TOC 

6.  IANA Considerations

This document does not require any action by IANA.



 TOC 

7.  Security Considerations

This document does not define any new protocol, and has no inherent security considerations. It does discuss criteria for the selection of a security protocol, chief among them being security.



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

8.2. Informative References

[I-D.harkins-emu-eap-pwd] Harkins, D. and G. Zorn, “EAP Authentication Using Only A Password,” draft-harkins-emu-eap-pwd-14 (work in progress), April 2010 (TXT).
[I-D.harkins-ipsecme-spsk-auth] Harkins, D., “Secure PSK Authentication for IKE,” draft-harkins-ipsecme-spsk-auth-01 (work in progress), March 2010 (TXT).
[I-D.sheffer-emu-eap-eke] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, “An EAP Authentication Method Based on the EKE Protocol,” draft-sheffer-emu-eap-eke-06 (work in progress), April 2010 (TXT).
[RFC2945] Wu, T., “The SRP Authentication and Key Exchange System,” RFC 2945, September 2000 (TXT).
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, “Using the Secure Remote Password (SRP) Protocol for TLS Authentication,” RFC 5054, November 2007 (TXT).
[RFC5683] Brusilovsky, A., Faynberg, I., Zeltsan, Z., and S. Patel, “Password-Authenticated Key (PAK) Diffie-Hellman Exchange,” RFC 5683, February 2010 (TXT).


 TOC 

Appendix A.  Change Log



 TOC 

A.1.  draft-sheffer-ipsecme-pake-criteria-00

Initial version.



 TOC 

Author's Address

  Yaron Sheffer
  Check Point Software Technologies Ltd.
  5 Hasolelim St.
  Tel Aviv 67897
  Israel
Email:  yaronf@checkpoint.com