TOC 
Network Working GroupY. Sheffer
Internet-DraftCheck Point
Intended status: InformationalS. Fluhrer
Expires: September 23, 2010Cisco
 March 22, 2010


HUSH: Using HUmanly memorable SHared secrets with IKEv2
draft-sheffer-ipsecme-hush-00

Abstract

This document defines a new mode for IKEv2, where both peers can authenticate using a short, humanly memorable shared secret. This mode is based on the EKE protocol.

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 23, 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.  Overview
4.  Protocol Sequence
    4.1.  The IKE_SA_INIT Exchange
    4.2.  The IKE_HUSH Exchange
        4.2.1.  Message #1
        4.2.2.  Message #2
        4.2.3.  Message #3
        4.2.4.  Message #4
5.  Protocol Formats
    5.1.  Encrypt Payload
    5.2.  Protect Payload
6.  Cryptographic Details
    6.1.  Diffie-Hellman Groups
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Change Log
    A.1.  -00
§  Authors' Addresses




 TOC 

1.  Introduction

There is strong interest in a simple method for bootstrapping an IKE [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) security association between two peers, requiring neither PKI nor AAA infrastructure. Although IKEv2 supports EAP-based authentication in part to provide for this capability, it has been claimed that the use of an extra authentication layer/protocol adds little benefit and increases complexity.

This protocol integrates the well known EKE protocol [BM92] (Bellovin, S. and M. Merritt, “Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks,” May 1992.) into IKEv2, to provide password-based authentication. Some of the benefits of this protocol are:

This protocol is not intended for use in enterprise-scale remote access. As a result, only the basic authentication capability is provided. Some capabilities typically associated with the use of passwords for remote access include: password change and expiry, password recovery, and enforcement of password strength policy.

In this preliminary version of the protocol many issues are not yet covered, such as:



 TOC 

2.  Terminology

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.  Overview

This protocol attempts to preserve the general structure of IKEv2, minimizing the number of new constructs and round trips, while retaining IKE's security guarantees, including identity protection. The resulting protocol only adds one round trip to the shared secret authentication mode of IKEv2.

At a high level, the message exchange is as follows:


        Initiator                           Responder
        ---------                           ---------

HDR, SAi1, KEi, Ni, N(HUSH)

		    <- HDR, SAr1, KEr, Nr, N(HUSH)

HDR, SK{IDi, [IDr,], SAi2, TSi, TSr, Encrypt{Yi}} ->

		    <- HDR, SK{IDr, Encrypt{Yr}, Protect{Nr2}}

HDR, SK{AUTH, Protect{Ni2|Nr2}}

		    <- HDR, SK{AUTH, SAr2, TSi, TSr, Protect{Ni2}}

The changes to IKEv2 are summarized in the following list:



 TOC 

4.  Protocol Sequence

The protocol consists of a slightly extended IKE_SA_INIT exchange, followed by the 4-message IKE_HUSH exchange.



 TOC 

4.1.  The IKE_SA_INIT Exchange

During this exchange, the initiator sends an empty HUSH_SUPPORTED notification. If the responder understands this protocol and wishes to use it, it sends back another empty HUSH_SUPPORTED notification.

In addition, this protocol defines a new transform type for the IKE protocol, called "EKE D-H Group". Possible transforms are the EKE groups defined in Section 6.1 (Diffie-Hellman Groups). This transform type is negotiated between the initiator and responder with the usual SAi1, SAr1 payloads. If the initiator suspects that the responder does not support this protocol, it SHOULD also include a proposal that omits this transform, to allow the negotiation to revert to regular IKE. During successful negotiation, an EKE D-H Group MUST be negotiated if (and only if) the responder indicates support for this protocol.



 TOC 

4.2.  The IKE_HUSH Exchange

This exchange consists of two message pairs, and includes all payloads normally contained in the IKE_AUTH exchange. These latter payloads are not described in this subsection, in order to focus on the new HUSH payloads.



 TOC 

4.2.1.  Message #1

The initiator computes

Yi = g^x mod N,

where x is a randomly chosen number in the range 2 .. N-1, as defined by the negotiated Diffie-Hellman group. The randomly chosen number is the private key, and the calculated value is the corresponding public key. Each of the peers MUST use a fresh, random value for x on each run of the protocol.

Note: If Elliptic Curve Diffie-Hellman is used in a future version of this protocol, the corresponding additive group operations are to be understood.

The initiator generates the Encrypt payload (Section 5.1 (Encrypt Payload)),

Encrypt(prf+(password, "HUSH Password"), Yi),

where the literal string is encoded using ASCII with no zero terminator. The prf+ notation is as defined in [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). When using block ciphers, it may be necessary to pad Yi on the right, to fit the encryption algorithm's block size. In such cases, random padding MUST be used, and this randomness is critical to the security of the protocol. Randomness recommendations can be found in [RFC4086] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.).

If the password needs to be stored on the server, it is RECOMMENDED to store the randomized password value, i.e. prf+(password, ...), as a password-equivalent, rather than the cleartext password.

If the password is non-ASCII, it SHOULD be normalized by the sender before the message is constructed. The normalization method is SASLprep, [RFC4013] (Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” February 2005.). Note that the password is not null-terminated.



 TOC 

4.2.2.  Message #2

Similarly to Message #1, the responder picks a random private key, generates an ephemeral public key Yr, encrypts it by the expanded password and includes the resulting Encrypt payload in the message:

Encrypt(prf+(password, "HUSH Password"), Yr),

The responder now calculates

EkeSharedSecret = prf(0+, g^(x*y) mod N)

where the first argument to "prf" is a string of zero octets whose length is the output size of the base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result is of the same length. This extra application of the pseudo-random function is the "extraction step" of [I‑D.krawczyk‑hkdf] (Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” January 2010.).

The responder computes the encryption key:

Ke2 = prf+(EkeSharedSecret, "HUSH encryption" | IDi | IDr)

and the authetication (integrity protection) key:

Ka2 = prf+(EkeSharedSecret, "HUSH authentication" | IDi | IDr)

Now the responder can generate the Protect payload included in the message:

Protect(Ke2, Ka2, Nr2),

where Nr2 is a randomly generated binary string (nonce). Nr2 has length equal to the block size of the negotiated encryption algorithm for block ciphers, or 32 octets if this algorithm is a stream cipher. The responder sends this value as an Encrypt payload.



 TOC 

4.2.3.  Message #3

The initiator computes the EkeSharedSecret, Ke2 and Ka2 values as above.

It then picks a random nonce Ni2, of the same format as Nr2, concatenates the two nonces, and generates

Protect(Ke2, Ka2, Ni2 | Nr2),

In addition, it computes

AUTH = prf(prf(Shared Secret, Ni2 | Nr2 | IDi | IDr), <InitiatorSignedOctets>)

where the Shared Secret is the regular IKE shared secret, created by the IKE_SA_INIT exchange.



 TOC 

4.2.4.  Message #4

The responder verifies Nr2 and the received AUTH payload, and MUST terminate the protocol if either of them fails to verify. The responder generates

Protect(Ke2, Ka2, Ni2)

and

AUTH = prf(prf(Shared Secret, Ni2 | Nr2 | IDi | IDr), <ResponderSignedOctets>)

The initiator MUST verify the Ni2 and AUTH values when receiving Message #4.



 TOC 

5.  Protocol Formats



 TOC 

5.1.  Encrypt Payload

This payload contains encrypted, but non-integrity protected, data. Unfortunately the simpler term "Encrypted Payload" is used by IKEv2 for a payload that contains encrypted and integrity-protected data.

Compared to the IKE Encrypted Payload, this payload does not contain other embedded payloads. The payload is denoted Encrypt(key, data), and defined thus:




                        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  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |         (length is block size for encryption algorithm)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Length            |                               ~
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  Encrypted Data               ~
   ~                                                               ~
   ~               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |                                               ~
   +-+-+-+-+-+-+-+-+      Random Padding (0-255 octets)            ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The Encrypt Payload 



 TOC 

5.2.  Protect Payload

This payload contains encrypted and integrity protected data.

This payload is identical to the Encrypt Payload (Section 5.1 (Encrypt Payload)) with the addition of an integrity-protection ICV field. The payload is denoted by Protect(enc-key, integ-key, data) and defined as follows:




                        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  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |         (length is block size for encryption algorithm)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Length            |                               ~
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  Encrypted Data               ~
   ~                                                               ~
   ~               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |                                               ~
   +-+-+-+-+-+-+-+-+      Random Padding (0-255 octets)            ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Integrity Check Value (ICV)                  |
   |              (length depends on integrity algorithm)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The Protect Payload 



 TOC 

6.  Cryptographic Details



 TOC 

6.1.  Diffie-Hellman Groups

Many of the commonly used Diffie Hellman groups are inappropriate for use in EKE. Most of these groups use a generator which is not a primitive element of the group. As a result, an attacker running a dictionary attack would be able to learn at least 1 bit of information for each decrypted password guess.

Any MODP Diffie Hellman group defined for use in this protocol MUST have the following properties, to ensure that it does not leak a usable amount of information about the password:

  1. The generator is a primitive element of the group.
  2. The most significant 64 bits of the prime number are 1.
  3. The group's order p is a "safe prime", i.e. (p-1)/2 is also prime.

The last requirement is related to the strength of the Diffie Hellman algorithm, rather than the password encryption. It also makes it easy to verify that the generator is primitive.

We have defined the following groups. The Value column is used when negotiating the group. Additional groups may be defined through IANA allocation. Future non-MODP groups require a document to define their interaction with this protocol.

NameLengthValueDescription
Reserved   0  
DHGROUP_EKE_2 1024 1 The prime number of Group 2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.), with the generator 5 (decimal)
DHGROUP_EKE_5 1536 2 The prime number of Group 5 [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.), g=31
DHGROUP_EKE_14 2048 3 The prime number of Group 14 [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.), g=11
DHGROUP_EKE_15 3072 4 The prime number of Group 15 [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.), g=5
DHGROUP_EKE_16 4096 5 The prime number of Group 16 [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.), g=5
Available for allocation via IANA   6-127  
Reserved for private use   128-255  



 TOC 

7.  IANA Considerations

TBD: one notification, one transform type, two payloads.



 TOC 

8.  Security Considerations

Will be added.



 TOC 

9.  Acknowledgements

Much of this protocol is derived from [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.), and authors (and reviewers) of that draft are acknowledged.



 TOC 

10.  References



 TOC 

10.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).
[RFC3526] Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” RFC 3526, May 2003 (TXT).
[RFC4306] Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005 (TXT).


 TOC 

10.2. Informative References

[BM92] Bellovin, S. and M. Merritt, “Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks,” Proc. IEEE Symp. on Research in Security and Privacy , May 1992.
[BM93] Bellovin, S. and M. Merritt, “Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise,” Proc. 1st ACM Conference on Computer and Communication Security , 1993.
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, “Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman,” Advances in Cryptology, EUROCRYPT 2000 , 2000.
[I-D.krawczyk-hkdf] Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” draft-krawczyk-hkdf-01 (work in progress), January 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).
[PA97] Patel, S., “Number Theoretic Attacks On Secure Password Schemes,” Proceedings of the 1997 IEEE Symposium on Security and Privacy , 1997.
[RFC4013] Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” RFC 4013, February 2005 (TXT).
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” BCP 106, RFC 4086, June 2005 (TXT).


 TOC 

Appendix A.  Change Log

Note to RFC Editor: please remove this section before publication.



 TOC 

A.1.  -00

Initial version, a very rough draft.



 TOC 

Authors' Addresses

  Yaron Sheffer
  Check Point Software Technologies Ltd.
  5 Hasolelim St.
  Tel Aviv 67897
  Israel
Email:  yaronf.ietf@gmail.com
  
  Scott Fluhrer
  Cisco Systems.
  1414 Massachusetts Ave.
  Boxborough, MA 01719
  USA
Email:  sfluhrer@cisco.com