One document matched: draft-sheffer-ipsecme-pake-criteria-00.txt
Network Working Group Y. Sheffer
Internet-Draft Check Point
Intended status: Informational March 1, 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
Sheffer Expires September 2, 2010 [Page 1]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Selection Criteria . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Security Criteria . . . . . . . . . . . . . . . . . . . . . 4
3.2. Intellectual Property . . . . . . . . . . . . . . . . . . . 4
3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 5
4. Some Possible Candidates . . . . . . . . . . . . . . . . . . . 6
5. Comparison Table . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8
A.1. draft-sheffer-ipsecme-pake-criteria-00 . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Sheffer Expires September 2, 2010 [Page 2]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
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.
Sheffer Expires September 2, 2010 [Page 3]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
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].
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.
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.
o The protocol has good security "best practices", such as crypto
agility.
o The solution is based on a cryptographic protocol that has been
(openly) published some time ago, giving the cryptographic
community enough time to have reviewed it. Preferably, it was
published in a location where it is more likely to be reviewed,
e.g. a peer-reviewed crypto journal.
o The protocol has undergone thorough professional analysis. It's
best if protocol analyses by prominent cryptographers have been
published. If issued were uncovered, we would prefer repeat
analysis to have been undertaken on the fixed protocol.
o Some modern protocols have been mathematically proven secure under
various models. This is an attractive feature of such protocols.
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
Sheffer Expires September 2, 2010 [Page 4]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
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:
o Ideally, the proposal should be unencumbered. This property is
very difficult to prove, and each WG participant should attempt to
review the applicable patents and determine whether in fact they
do not apply to the proposal. Remember that independently
invented technology might still infringe a patent.
o In some cases the IPR situation is clear: if the protocol relies
on a specific patent, and believed to not require the use of any
other. This is mostly useful if the patent's licensing terms
(whether free or not) are known, and/or the patent's expiration
date is near.
o Many IETF participants, and the IETF as an organization, quite
naturally prefer freely licensed technology to non-free licensing
terms.
3.3. Other Considerations
A few additional criteria may be just as important:
o Protocols that have been specified within standards document
should be preferred over protocols that are only described in
scientific papers. Such description is typically insufficient to
provide interoperability, and may not be sufficient for a serious
security analysis.
Sheffer Expires September 2, 2010 [Page 5]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
o Likewise, cryptographic protocols that have been integrated into
the IKE framework have an advantage over those described only
within other security protocols.
o Finally, there are many engineering criteria that apply to any
protocol, including number of round trips, ease of implementation
etc.
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:
o IEEE P1363.2, Specifications for Password based Public Key
Cryptographic Techniques.
o ISO/IEC 11770-4:2006 Information technology - Security techniques
- Key management - Part 4: Mechanisms based on weak secrets.
5. Comparison Table
This is a very rough attempt at a comparative analysis. Many of the
details are incomplete, and/or controversial.
Sheffer Expires September 2, 2010 [Page 6]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
+------+-----------------------------+---------------+--------------+
| Name | Standards | Security | IPR |
| | | Analysis | |
+------+-----------------------------+---------------+--------------+
| EKE | [I-D.sheffer-emu-eap-eke] | Well analyzed | Patent from |
| | | security, | 1992 |
| | | since 1992, | (Lucent?), |
| | | several | due to |
| | | analysis | expire Oct. |
| | | papers | 2011. |
| | | published. | |
| SRP | SRP published as [RFC2945], | Published and | Patent held |
| | TLS-SRP is [RFC5054]. IEEE | unpublished | by Stanford |
| | 1363.2. | analysis by | University, |
| | | Bleichenbache | with a free |
| | | r. | license. |
| | | | Phoenix |
| | | | posted an |
| | | | IPR |
| | | | statement, |
| | | | but no |
| | | | request for |
| | | | reexaminatio |
| | | | n. |
| SPSK | [I-D.harkins-emu-eap-pwd], | Security | Explictly |
| | [I-D.harkins-ipsecme-spsk-a | analysis by | not |
| | uth]. | NIST | patented. |
| | | cryptographer | May or may |
| | | s. | not infringe |
| | | | on existing |
| | | | patents. |
| SPEK | IEEE 1363.2. | [To be | Patents held |
| E | | completed] | by Phoenix. |
| PAK | Published as [RFC5683]. | [To be | Patents held |
| | IEEE 1363.2. | completed] | by Lucent. |
+------+-----------------------------+---------------+--------------+
6. IANA Considerations
This document does not require any action by IANA.
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.
Sheffer Expires September 2, 2010 [Page 7]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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-13 (work in
progress), February 2010.
[I-D.harkins-ipsecme-spsk-auth]
Harkins, D., "Secure PSK Authentication for IKE",
draft-harkins-ipsecme-spsk-auth-00 (work in progress),
November 2009.
[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-04 (work in progress),
January 2010.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, September 2000.
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
"Using the Secure Remote Password (SRP) Protocol for TLS
Authentication", RFC 5054, November 2007.
[RFC5683] Brusilovsky, A., Faynberg, I., Zeltsan, Z., and S. Patel,
"Password-Authenticated Key (PAK) Diffie-Hellman
Exchange", RFC 5683, February 2010.
Appendix A. Change Log
A.1. draft-sheffer-ipsecme-pake-criteria-00
Initial version.
Sheffer Expires September 2, 2010 [Page 8]
Internet-Draft Password Based Authentiction in IKEv2 March 2010
Author's Address
Yaron Sheffer
Check Point Software Technologies Ltd.
5 Hasolelim St.
Tel Aviv 67897
Israel
Email: yaronf@checkpoint.com
Sheffer Expires September 2, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:53:10 |