• Registered: 2014-04-01
  • Posts: 4

Topic: [SOLVED] wolfSSL support for RFC 4279

Hi,
I am using wolfSSL embedded SSL version 2.9.4. I modified the suites tables to add TLS_DHE_PSK_WITH_AES_128_GCM_SHA256.

According to RFC 4279, I do not use certificates in the handshaking between my server and my client. However I found in many places the "NO_CERTS" preprocessor directive that forbids me to use the serverDH_P field, for instance, of the WOLFSSL_CTX struct.

If I try to use certificates with Diffie Hellman key exchange and with PSK, however, I ran into a problem with the SendCertificate when allocating an output buffer. Long story. But in the internal.c initialization section there are lots of areas that are affected by the NO_CERTS directive which also include data structures used by Diffie Hellman key exchange.

Also in the SendServerKeyExchange function in internal.c where ssl->specs.kea == diffie_hellman_key, the code assumes we have a private key, which is a RSA private key but not a pre shared key.

I went through my wolfSSL code and where it had the NO_CERTS, I added a || (!defined(NO_DH) && !defined(NO_PSK)) and I got a NO_PRIVATE_KEY error in the sendServerKeyExchange

My keys.c has this block I added:

#ifdef BUILD_TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
    case TLS_DHE_PSK_WITH_AES_128_GCM_SHA256:
        ssl->specs.bulk_cipher_algorithm = cyassl_aes_gcm;
        ssl->specs.cipher_type = aead;
        ssl->specs.mac_algorithm = sha256_mac;
        ssl->specs.kea = diffie_hellman_kea;
        ssl->specs.sig_algo = anonymous_sa_algo;
        ssl->specs.hash_size = SHA256_DIGEST_SIZE;
        ssl->specs.pad_size = PAD_SHA;
        ssl->specs.static_ecdh = 0;
        ssl->specs.key_size = AES_128_KEY_SIZE;
        ssl->specs.block_size = AES_BLOCK_SIZE;
        ssl->specs.iv_size = AEAD_IMP_IV_SZ;
        ssl->specs.aead_mac_size = AES_GCM_AUTH_SZ;

        break;
#endif

Am I totally off base here?

thanks

Bill

Share

  • Registered: 2014-04-01
  • Posts: 4

Re: [SOLVED] wolfSSL support for RFC 4279

To be precise, TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 is described in RFC 5487, however the key exchanges are performed as in RFC 4279:

"The following six cipher suites use the new authenticated encryption
   modes defined in TLS 1.2 with AES in Galois Counter Mode [GCM].  The
   cipher suites with the DHE_PSK key exchange algorithm
   (TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 and
   TLS_DHE_PSK_WITH_AES_256_GCM_SHA348) provide Perfect Forward Secrecy
   (PFS).

      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256        = {0x00,0xA8};
      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384        = {0x00,0xA9};
      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256    = {0x00,0xAA};
      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384    = {0x00,0xAB};
      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256    = {0x00,0xAC};
      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384    = {0x00,0xAD};

   These cipher suites use authenticated encryption with additional data
   (AEAD) algorithms, AEAD_AES_128_GCM and AEAD_AES_256_GCM, as
   described in RFC 5116.  GCM is used as described in [RFC5288].

   The PSK, DHE_PSK, and RSA_PSK key exchanges are performed as defined
   in [RFC4279]."

Share

  • john
  • Moderator
  • Offline
  • From: Seattle, WA
  • Registered: 2011-11-14
  • Posts: 148

Re: [SOLVED] wolfSSL support for RFC 4279

We recently added many DHE-PSK cipher suites last week. The code specifies a new key-exchange algorithm, dhe_psk_kea, which is handled alongside the diffie_hellman_kea and psk_kea. So, you might want to check that out and see if solves your issue. The DHE-PSK key exchange doesn't sign the message like in ECDHE and regular DH(E).

john's Website

Share

  • Registered: 2014-04-01
  • Posts: 4

Re: [SOLVED] wolfSSL support for RFC 4279

Thanks John,

Not sure how to mark this "solved" but I will try...

- Bill

Share