Internet DRAFT - draft-budronimccusker-milagrotls

draft-budronimccusker-milagrotls



 



Network Working Group                            A. Budroni, K. McCusker
Internet-Draft                                               MIRACL Ltd.
Intended Status: Informational                              June 3, 2016
Expires: December 5, 2016                                               


  Milagro TLS: pairing-based cryptography for Transport Layer Security
                  draft-budronimccusker-milagrotls-00

Abstract

   This document introduces two key exchange algorithms based on
   Pairing-Based Cryptography (PBC) for the Transport Layer Security
   (TLS) protocol. In particular, it specifies the use of two identity-
   based key exchange algorithms for the TLS handshake.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current.

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

   This Internet-Draft will expire on December 5, 2016.

Copyright Notice

   Copyright (c) 2016 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 Simplified BSD License.

 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 1]

Internet-Draft                Milagro TLS                   June 3, 2016


Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Requirements Notation . . . . . . . . . . . . . . . . . . . . .  3
     2.1 Definitions  . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2 Abbreviations  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.3 Conventions  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . .  4
     3.1 MILAGRO_CS . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2 MILAGRO_P2P  . . . . . . . . . . . . . . . . . . . . . . . .  5
   4. Data Structures and Computations  . . . . . . . . . . . . . . .  6
     4.1 ClientHello Extension  . . . . . . . . . . . . . . . . . . .  7
     4.2 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
     4.3 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
   5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
     6.1 MILAGRO_CS . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1 MILAGRO_P2P  . . . . . . . . . . . . . . . . . . . . . . . . 11
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
     8.2 Informative References . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12



1. Introduction

   Pairing-Based Crypto (PBC) is emerging as a  solution to complex
   problems that proved intractable to the standard mathematics of
   Public-Key Cryptography. An example of such a problem would be
   Identity-Based Encryption, whereby the identity of a client can be
   used as their public key [11].

   PBC is based on the use of a bi-linear map defined on an elliptic
   curve E

                         e: G1 X G2 -> GT

   where G1 is defined as a group of points on E, G2 is defined as a
   group of points on a twist of E over an extension field. Both groups
   are of prime order q. GT is a finite extension.

   Milagro TLS proposes the use of PBC for mutually authenticated key
   agreement. There are two new key exchange algorithms in this draft:
   Peer-to-Peer (P2P) and Client-Server. The P2P solution uses the Chow-
   Choo protocol and the Client-Server solution uses the MPIN Protocol
   [9,10].
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 2]

Internet-Draft                Milagro TLS                   June 3, 2016


   Milagro TLS uses a curve that has security at the AES-128 level.

   This document describes an addition to TLS 1.2 [1] to support PBC. In
   particular, it defines

   o Milagro_CS: a key exchange algorithm based on MPIN-FULL protocol 
     [9]. This is a Client-to-Server protocol that allows mutually
     authenticated key agreement. In this protocol the client secrets
     are in G1 and the server secret is in G2.  For a Type-3 pairing
     there is assumed to be no computable isomorphism between these
     groups, even though both are of the same order.

   o Milagro_P2P: a key exchange algorithm based on the Chow-Choo
   protocol
     [10]. It can operate in P2P or client/server mode. Users of this
     protocol are issued sender keys in G1 and receiver keys in G2. The
     server, which sends the ServerKeyExchange message, is considered
     the sender in this protocol.

2. Requirements Notation

   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 [2].

2.1 Definitions

   Digital Identity: Digital Identity is the data that uniquely
   describes a person or a thing, and typically contains some
   information about that entity's relationships.

2.2 Abbreviations

   ECC Elliptic Curve Cryptography

   PBC Pairing-Based Cryptography

   AES Advanced Encryption Standard

   TA Trusted Authority

   P2P Peer-to-Peer

   Milagro_CS Milagro Client-to-Server

   Milagro_P2P Milagro Peer-to-Peer

   ECDH Elliptic Curve Diffie Hellman 
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 3]

Internet-Draft                Milagro TLS                   June 3, 2016


   E is an ordinary pairing-friendly elliptic curve over a finite field
   F, defined by a fixed prime modulus p

2.3 Conventions

   IdC: Digital identity of the client

   IdS: Digital identity of the server

   H1: Maps string value to a point on the curve in G1. 

   H2: Maps string value to a point on the curve in G2

   Hq: Hashes inputs to an integer modulo the curve order q.

   Hg: Generate AES key

   SHA-256: Performs the SHA256 function.

3. Key Exchange Algorithms

3.1 MILAGRO_CS

   Here we briefly resume the main steps of the MPIN-FULL key exchange
   algorithm, see [8] and [9] for details.

   Let A = H1(IdC) be a point on G1, where IdC is the client's identity,
   and let Q be a generator of the group G2. The TA provides the client
   key s.A, in G1 and the server key s.Q, in G2.

   MPIN Full was envisaged as a two factor authentication solution but
   in this context, as this is a machine to machine protocol, there is
   no requirement for a second factor and therefore the PIN is set to
   zero in the code. It supports also the use of time permits, which is
   a tool that provide a simple alternate revocation capability. The
   idea is that the server includes an explicitly described time slot in
   its construction of Alice's hashed identity. Unless Alice has a
   corresponding "Time permit" for the same time slot, she cannot
   complete the protocol.

   The ClientHello message MUST have an extension which contains three
   public parameters:

   - IdC, the identity of the client. This can be the identity in clear 
     or the hash of identity. In the latter case the IdC is encrypted
     after the session key is established and sent to the server to
     complete client authentication.

 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 4]

Internet-Draft                Milagro TLS                   June 3, 2016


   - U = x.(H1(IdC)) where x is a random number modulo the curve order. 
     When time permits are used then this value is set to U =
     x.(H1(IdC)+H1(d|SHA-256(IdC))), where d is the Epoch days.

   - t, the epoch time at which authentication occurred.

   - V = -(x+y)(s.A), where y = Hq(t|U) and A = H1(IdC).
     When time permits are enabled then a time permit must be added to
     s.A prior to multiplication. 

   The server itself calculates A by applying the same hash function H1
   to the claimed digital identity i.e. A is H1(IdC) or  H1(IdC) +
   H1(d,SHA-256(IdC) in the case of time permits being used. Then the
   Server MUST check that e(V,Q).e(U+yA,s.Q) = 1. If this tests fails
   then the connection is terminated by the server with a proper alert
   message and the attempted Client connection is rejected.

   Through the ServerKeyExchange message, the server sends an  ECDH
   public key W=w.A, where w is a random number modulo the curve order
   and A is H1(IdC) or H1(IdC) + H1(d,SHA-256(IdC) if time permits used.

   Through the ClientKeyExchange message, the client send its ECDH
   public key R=r.A, where r is a random number modulo the curve order.

   At this point, both the client and the server are able to compute a
   16-bytes shared premaster secret:

   - The client first computes the parameter h = Hq(A,U,y,V,R,W), then 
     computes the premaster secret as K = Hg(e(s.A,Q)^(r+h)|x.W).

   - The server first computes the parameter h = Hq(A,U,y,V,R,W), then 
     computes the premaster secret as K = Hg(e(R+h.A,s.Q)|w.U).

     See [9] for more details.

3.2 MILAGRO_P2P

   Here we briefly resume the main steps of the Chow-Choo key exchange
   Algorithm [10].

   Choo-Chow key exchange algorithm is designed for communications peer-
   to-peer. The TA provides the server with a sender key in G1 i.e.
   SKeyG1 and client with receiver key in G2 I.e. CKeyG2 based on their
   respective identities. 

   The main steps of the algorithm are:

   - The server computes a random integer x modulo the curve order, 
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 5]

Internet-Draft                Milagro TLS                   June 3, 2016


     computes a point on the group G1 as PsG1 = x.H1(IdS) which is its
     public parameter and sends the pair (IdS,PsG1) to the client.

   - The client receives the pair of parameter from the server, computes
     two random integers Y and W modulo the curve order, compute the
     following; PcG2 = Y.H2(IdC), PgG1 = W.H1(IdS), pic =
     Hq(PcG2||PsG1||PgG1||IdS), pis = Hq(PsG1||PcG2||PgG1||IdC) and the
     value k = e(pis.H(IdS)+PsG1,(y+pic).CKeyG2).

   - client computes the premaster secret as K = Hg(k,w.PsG1).

   - client sends the triple (IdC,PsG1,PgG1) to server.

   - server receives the parameters from the client and computes the
   following
     pis = Hq(PsG1||PcG2||PgG1), pic = Hq(PcG2||PsG1||PgG1) and the
     value k = e((x+pis).SKeyG1,pic.B+PcG2).

   - server compute the premaster secret as K = Hg(k,x.PsG1).

4. Data Structures and Computations

   This document introduces two new key exchange algorithms for TLS that
   use PBC to compute the TLS premaster secret. The derivation of the
   TLS master secret from the premaster secret and the subsequent
   generation of bulk encryption/MAC keys and initialization vectors is
   independent of the key exchange algorithm and not impacted by the
   introduction of PBC and ECC.

                         enum {  
                               Milagro_CS,
                               Milagro_P2P,
                         } KeyExchangeAlgorithm;

   The first key exchange algorithm is Milagro_CS and it is designed for
   client-to-server communications. It is based on the MPIN-FULL key
   exchange protocol [9], which is an extension of the M-Pin
   Authentication Protocol [8].

   The second key exchange algorithm is Milagro_P2P and it is designed
   for peer-to-peer communications. It is based on the CHOW-CHOO
   protocol [10]. 

   Here we summarize the steps of TLS-Handshake used by those two key
   exchange algorithms.

          Client                                       Server
          ------                                       ------
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 6]

Internet-Draft                Milagro TLS                   June 3, 2016


        ClientHello           --------->
                                                     ServerHello
                                                 ServerKeyExchange
                              <---------           ServerHelloDone
      ClientKeyExchange 
     (ChangeCipherSpec)
         Finished             --------->
                                                  (ChangeCipherSpec)
                              <---------               Finished

     Application Data         <-------->           Application Data

   The following messages of TLS-Handshake MUST NOT be sent for those
   two key exchange algorithms: (Server)Certificate, CertificateRequest,
   (Client)Certificate and CertificateVerify.


4.1 ClientHello Extension

   This section specifies a TLS extension that can be included with the
   ClientHello message as described in [3], the Milagro_CS Extension.

   When this extension are sent:

     The extension MUST be sent along with any ClientHello message that
     proposes Milagro_CS key exchange algorithms and it MUST NOT be sent
     with any other ClientHello message that doesn't proposes this
     cipher.

   Meaning of this extension:

     This extension allow the Client to authenticate itself with the
     Server and to exchange part of the parameters that will be used to
     compute the premaster secret.

   Structure of these extensions:

     As described in [3], two octets of are used to indicate the
     extension type. In case of Milagro_CS extension the octets are
     0x0025. The general structure of TLS extensions is described in
     [3], and this specification adds a new type to ExtensionType.

               enum {  Milagro_CS_ext } ExtensionType;

                    struct {
                            uint16 length_hash_IdC,
                            uint16 length_U,
                            uint16 length_V,
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 7]

Internet-Draft                Milagro TLS                   June 3, 2016


                            opaque hash_IdC[length_hash_IdC],
                            opaque U[length_U],
                            opaque V[length_V],
                            uint32 time_value,
                            (255) 
                    } Milagro_CS_ext;

     length_hash_IdC, length_U, length_V: length of the parameters.

     hash_IdC: hash of the client's identity.

     U: first parameter sent by the client.

     V: second parameter sent by the client.

     time_value: current epoch time in seconds.

   Actions of the Server:

     If Milagro_CS is between the key exchange algorithms available of
     the server, then he MUST check if the time_value received from the
     client differs too much from the current time. If the difference is
     more than a fixed value then he has to refuse the client. If this
     check has a successful ending it is  RECOMMENDED, regardless of the
     chosen cipher suite, that he tries to authenticate the Client as
     explained in 3.1, and, in case of failing, he has to refuse the
     client.

     See [8] for details about the authentication.

4.2 Server Key Exchange

   This document introduces two new ServerKeyExchange messages, one for
   each key exchange algorithm. 

   If the cipher suite chosen by the server has Milagro_CS as key
   exchange algorithm, then the server MUST compute the parameter W, as
   explained in 3.1 and send it.

   If the cipher suite chosen by the server has Milagro_P2P as key
   exchange algorithm, then the server MUST compute the the public
   parameter PsG1 as explained in 3.2 and send it with its digital
   identity IdS.

   The ServerKeyExchange message is extended as follows.

               select (KeyExchangeAlgorithm) {
                    case Milagro_CS:
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 8]

Internet-Draft                Milagro TLS                   June 3, 2016


                         uint16   length_W;
                         opaque   W[length_W];
                    case Milagro_P2P:
                         uint16   length_IdS;
                         uint16   length_PsG1;
                         opaque   IdS[length_IdS];
                         opaque   PsG1[length_PsG1];
               } ServerKeyExchange;

4.3 Client Key Exchange

   If the cipher suite chosen by the server has Milagro_CS as key
   exchange algorithm, then the client MUST compute the parameter R, as
   explained in 3.1 and send it.

   If the cipher suite chosen by the server has Milagro_P2P as key
   exchange algorithm, then the client MUST compute the parameters PgG1
   and PcG2 as explained in 3.2 and send them with its digital identity
   IdC.

   The ClientKeyExchange message is extended as follows.

               select (KeyExchangeAlgorithm) {
                    case Milagro_CS:
                         uint16   length_R;
                         opaque   R[length_R];
                    case Milagro_P2P:
                         uint16   length_IdC;
                         uint16   length_PgG1;
                         uint16   length_PcG2;
                         opaque   IdC[length_IdC];
                         opaque   PgG1[length_PgG1];
                         opaque   PcG2[length_PcG2];
               } ClientKeyExchange;

5. Cipher Suites

   The table below defines new cipher suites that use the key exchange
   algorithms specified in Section 3.

  CipherSuite TLS_MILAGRO_CS_WITH_AES_128_GCM_SHA256       = {0xC0,0xB1}
  CipherSuite TLS_MILAGRO_CS_WITH_AES_128_GCM_SHA512       = {0xC0,0xB2}
  CipherSuite TLS_MILAGRO_CS_WITH_CAMELLIA_128_GCM_SHA256  = {0xC0,0xB3}
  CipherSuite TLS_MILAGRO_CS_WITH_CAMELLIA_128_GCM_SHA512  = {0xC0,0xB4}
  CipherSuite TLS_MILAGRO_CS_WITH_3DES_EDE_CBC_SHA256      = {0xC0,0xB5}
  CipherSuite TLS_MILAGRO_CS_WITH_3DES_EDE_CBC_SHA512      = {0xC0,0xB6}

  CipherSuite TLS_MILAGRO_P2P_WITH_AES_128_GCM_SHA256      = {0xC0,0xB7}
 


BUDRONI_MCCUSKER       Expires: December 5, 2016                [Page 9]

Internet-Draft                Milagro TLS                   June 3, 2016


  CipherSuite TLS_MILAGRO_P2P_WITH_AES_128_GCM_SHA512      = {0xC0,0xB8}
  CipherSuite TLS_MILAGRO_P2P_WITH_CAMELLIA_128_GCM_SHA256 = {0xC0,0xB9}
  CipherSuite TLS_MILAGRO_P2P_WITH_CAMELLIA_128_GCM_SHA512 = {0xC0,0xC0}
  CipherSuite TLS_MILAGRO_P2P_WITH_3DES_EDE_CBC_SHA256     = {0xC0,0xC1}
  CipherSuite TLS_MILAGRO_P2P_WITH_3DES_EDE_CBC_SHA512     = {0xC0,0xC2}

   The key exchange method, cipher, and hash algorithm for each of these
   cipher suites are easily determined by examining the name. Ciphers
   (other than AES ciphers) and hash algorithms are defined in [1]. AES
   cipher is defined in [5], GCM in [6] and the hash algorithm is
   defined in [7].

   The cipher suite name space is maintained by IANA.  See Section 7 for
   information on how new value assignments are added.

6. Security Considerations

   For TLS handshakes using PBC cipher suites, the security
   considerations in appendices D, E and F of [1] apply accordingly.

   Security discussion specific to PBC can be also found in [11].

   Implementers and users must also consider whether they need forward
   secrecy.  Forward secrecy refers to the property that session keys
   are not compromised if the static, certified keys belonging to the
   server and client are compromised.  The MILAGRO_CS and MILAGRO_P2P
   key exchange algorithms provide forward secrecy protection in the
   event of server and/or client's secret compromise.


6.1 MILAGRO_CS

   A replay-attack might be mounted by re-sending the parameters sent
   with the extension of ClientHello from a previous conversation. This
   will not be successful if the difference between the current time on
   the server and time parameter in the ClientHello message is too
   large.

   An active attacker might allow the server to complete the first part
   of the protocol and then attempt to hijack the link before the
   calculation of the key. But observe how the value of x is re-used for
   the calculation of the Diffie-Hellman component of the key. This
   binds both parts of the protocol together and effectively blocks any
   hijacking attempt.

   A Key Compromise Impersonation (KCI) attack, whereby an attacker
   steals the client credentials and poses as a valid server, is
   impossible to mount due to fact that random integer r is used in the
 


BUDRONI_MCCUSKER       Expires: December 5, 2016               [Page 10]

Internet-Draft                Milagro TLS                   June 3, 2016


   key agreement protocol.

6.1 MILAGRO_P2P

   This key exchange algorithm has been proved secure under the
   Bilinear-Diffie-Hellman (BDH) assumption in the Canetti-Krawczyk
   [10].

   Other security discussions about MILAGRO_P2P key exchange algorithm
   can be found in [10].

7. IANA Considerations

   This document introduces in section 4.1 and 5 some additions to 
   Transport Layer Security (TLS) Parameters.

   Any assignments in this document require IETF Consensus action [4].


8. References

8.1 Normative References

   [1]   T. Dierks,  E. Rescorla, "The Transport Layer Security (TLS) 
         Protocol Version 1.2", RFC 5246, August 2008

   [2]   Bradner S., "Key words for use in RFCs to Indicate Requirement 
         Levels", RFC 2119, March 1997

   [3]   D. Eastlake, "Transport Layer Security (TLS) Extensions:
         Extension Definitions", RFC 6066, January 2011.

   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 
         Considerations Section in RFCs", RFC 5226, May 2008.

8.2 Informative References

   [5]   National Institute of Standards and Technology,
         "Specification for the Advanced Encryption Standard (AES)",
         FIPS 197, November 2001.

   [6]   National Institute of Standards and Technology,
         "Recommendation
         for Block Cipher Modes of Operation: Galois/Counter Mode (GCM)
         for Confidentiality and Authentication", SP 800-38D, November
         2007.

   [7]   National Institute of Standards and Technology, "Secure Hash 
 


BUDRONI_MCCUSKER       Expires: December 5, 2016               [Page 11]

Internet-Draft                Milagro TLS                   June 3, 2016


         Standard", FIPS PUB 180-4, August 2015.

   [8]   Scott, M. "M-Pin: A Multi-Factor Zero Knowledge Authentication 
         Protocol", Miracl Labs.

   [9]   Scott, M. "M-Pin Full Technology (Version 3.0)", Miracl Labs.

   [10]  Sherman S.M. Chow and Kim-Kwang Raymond Choo, "Strongly-Secure 
         Identity-based Key Agreement and Anonymous Extension",
         Cryptology ePrint Archive, Report 2007/018,2007.

   [11]  D. Boneh and M. Franklin. Identity-based encryption from the 
         Weil pairing. SIAM Journal of Computing, 32(3):586-615, 2003.

Authors' Addresses

   Alessandro Budroni
   MIRACL
   Email: alessandro.budroni@miracl.com

   Kealan McCusker
   MIRACL
   Email: kealan.mccusker@miracl.com




























BUDRONI_MCCUSKER       Expires: December 5, 2016               [Page 12]